aws_availability_zones proposes changes on each plan and apply

[icollar]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

• Terraform: v0.13.0
• Terraform AWS Provider: 3.1.0

Affected Resource(s)

• aws_availability_zones

Note: this might affect other resources that use a timestamp as an id.

Terraform Configuration Files

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "3.1.0"
    }
  }
}

provider "aws" {
  region = "eu-west-1"
}

data "aws_availability_zones" "a" {}

Output

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.aws_availability_zones.a: Refreshing state... [id=2020-08-10 20:17:30.88838418 +0000 UTC]

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
 <= read (data resources)

Terraform will perform the following actions:

  # data.aws_availability_zones.a will be read during apply
  # (config refers to values not yet known)
 <= data "aws_availability_zones" "a"  {
        group_names = [
            "eu-west-1",
        ]
      ~ id          = "2020-08-10 20:31:41.366912564 +0000 UTC" -> "2020-08-10 20:31:42.66423862 +0000 UTC"
        names       = [
            "eu-west-1a",
            "eu-west-1b",
            "eu-west-1c",
        ]
        zone_ids    = [
            "euw1-az1",
            "euw1-az2",
            "euw1-az3",
        ]
    }

Plan: 0 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Expected Behavior

Data resource should not be considered changed. Executing a plan with -detailed-exitcode should pass.

Actual Behavior

Data resource is be considered changed, causing plan -detailed-exitcode to fail when no resources need updating.

Steps to Reproduce

1. terraform apply
2. terraform plan -detailed-exitcode

References

• aws_availability_zones started proposing changes on each apply #14405 - originally reported
• data-source/aws_availability_zones: Fix group_names attribute to be Computed instead of Optional #14412 - original fix

[icollar]

FYI, anyone looking for a crude workaround could do something like this:

terraform plan -no-color > output
cat output
grep -qP '^Plan: 0 to add, 0 to change, 0 to destroy\.$' output

[bflad]

Hi @icollar 👋 Sorry for the confusion here, while the group_names fix applied in Terraform AWS Provider version 3.1.0 was an actual issue, it was not the only issue occurring.

There was some unexpected changes with data source handling that occurred in the Terraform CLI version 0.13.0 release that are causing this additional data source output in addition to the unstable id attribute in the output. There are now larger tracking issues for both sides of this so to consolidate efforts and discussions, I'm going to close this in preference of them:

• Handle semantically equivalent changes from the legacy SDK when planning data sources terraform#25812
• Data sources with non-deterministic IDs show perpetual diff with Terraform 0.13 (R015, R016, R017 linters) #14579

Please upvote and subscribe to those for further updates. 👍

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!