Closed joey-coleman closed 1 year ago
I'm seeing the same issue with aws_route53_health_check
and aws_ssm_parameter
. This can triggered using localstack.
Start localstack
with e.g. docker run --rm -it -e SERVICES=ssm -p 4566:4566 localstack/localstack:latest
.
The minimal example I used was this:
./main.tf
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
}
}
}
provider "aws" {
region = "us-east-1"
access_key = "0"
secret_key = "0"
s3_force_path_style = true
skip_credentials_validation = true
skip_metadata_api_check = true
skip_requesting_account_id = true
endpoints {
ssm = "http://localhost:4566"
}
default_tags {
tags = {
one = "two"
}
}
}
locals {
name = "example"
}
resource "aws_ssm_parameter" "example" {
name = local.name
type = "String"
value = "example"
}
module "m" {
source = "./m"
depends_on = [aws_ssm_parameter.example]
name = local.name
}
./m/main.tf
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
}
}
}
data "aws_region" "current" {}
locals {
name = "${data.aws_region.current.name}.${var.name}"
}
variable "name" {
type = string
}
resource "aws_ssm_parameter" "example" {
name = local.name
type = "String"
value = "example"
tags = {
name = local.name
}
}
Worth to note is perhaps that if default_tags
is removed on the provider the issue is not triggered.
There are a large number of similar reports of this, the most active in terms of comments appears to be https://github.com/hashicorp/terraform-provider-aws/issues/19583
Hey all 👋 Thank you very much for taking the time to raise this! This was addressed with #29747, which was included in version 5.0.0
of the provider. With that in mind, we'll close this issue. If you experience additional issues with the provider, please do open a new issue to let us know.
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
There appears to be an issue with inconsistent final plan error on tags_all when adding or overriding tags with values that are "known after apply".
Community Note
Terraform CLI and Terraform AWS Provider Version
Affected Resource(s)
Potentially others contained in a module; these are just the ones I was using
Terraform Configuration Files
Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
./main.tf
./tgw/tgw.tf
./peering/peering.tf
Debug Output
Shell transcript from
terraform apply
of above scriptExpected Behavior
The final plan should not have been inconsistent — if a resource's tags value is
(known after apply)
then terraform likely should not get upset thattags_all
changed as a result.Actual Behavior
An inconsistent final plan error as the tags changed after a data resource became available.
Steps to Reproduce
terraform apply
on the files included aboveImportant Factoids
This is a cut-down example — I do (think I) need to use the modules in this way. In my full script, without depends_on, I get races between parts of of the tgw module finishing and the parts of the peering module that depend on those bits of the tgw module.
Without the depends_on in the module call sites, the data.aws_region data sources inside the peering module are fully determined in the plan, rather than being "known after apply". I don't think that has to be the case as the aws_region of a provide isn't going to change.