Upgrade terraform and aws provider - compatibility

I am upgrading terraform 0.14 aws provider 2.66.0 to hopefully terraform 0.15. However I am running into lots of changes being detected and I don’t know if it is because I need to upgrade the aws provider first or the terraform version.

For example …

~ resource "aws_cloudfront_distribution" "s3_distribution" {
      + default_root_object            = ""
        id                             = "BLAHBLAHBLAH"
        tags                           = {
            "Environment" = "stage1"
            "Terraform"   = "true"
            "Workspace"   = "stage1"
        }
      + web_acl_id                     = ""
        # (16 unchanged attributes hidden)





      ~ viewer_certificate {
          # Warning: this attribute value will be marked as sensitive and will not
          # display in UI output after applying this change. The value is unchanged.
          ~ acm_certificate_arn            = (sensitive)
          + iam_certificate_id             = ""
            # (3 unchanged attributes hidden)
        }

Should I upgrade the aws provider first to v3? Or I push on doing terraform to 0.15 first and then aws provider to v3. I am confused about what provider version goes with what version of terraform.

Compatibility is completely up to the specific provider. Each provider version will have a minimum supported version of Terraform core, so you may find that the latest provider is already compatible with your version of Terraform.

In that case it is then a choice of which bit you upgrade first. You might find that it is more likely that code changes are needed for the provider update than the Terraform update, but otherwise the order is up to you.

1 Like

This output seems to suggest that the new version of the provider has some additional arguments which have default values and so the plan is showing the addition of those arguments with the value set to the default.

This is therefore a prompt that applying with the new version will set those to their default values and that you may wish to reset them to different values in your configuration if you’d prefer to use a non-default value.

If you accept this plan then Terraform will ask the provider to apply the change and so it will be up to the provider to decide what applying this change would mean, but typically a change like this would end up being an insignificant update that just sets everything how it is already set, as long as those new arguments already have the default values in the remote system too and so setting them explicitly to default will have no material effect.

The one Terraform Core specific change here is that Terraform v0.15 introduced the full handling of sensitive values and so Terraform is telling you that one of the arguments will be classified as sensitive after you apply. That’s a Terraform-state-only change and so applying that one in particular will just write some new metadata into the state to remember that the argument is sensitive so that it won’t show up in contexts like terraform show. That’s independent of the other changes you see, but I expect you see them both together due to upgrading both Terraform CLI and the provider at the same time.

1 Like