Closed jmanno closed 6 months ago
Voting for Prioritization
Volunteering to Work on This Issue
I wanted to add a note regarding impact to bring attention to this issue.
We have implemented dynamic global tags to ensure all our infrastructure resources adhere to our company's cloud tagging policy, which mandates certain tags for governance and operational efficiency. This setup has been operational and compliant with our policies for several months, verified through automated checks during our code review process.
Recently, we encountered this issue where the tags_all
attribute is not consistently rendered across all resources, leading to a failure in our automated compliance checks. This inconsistency prevents us from successfully deploying our infrastructure due to strict tag enforcement policies on our cloud environment, significantly impacting our deployment workflows.
Some accounts have AWS SCP rules in place to stop changes that are missing the tags required.
This situation has become a critical blocker for us, as we rely on the dynamic global tags functionality to meet compliance requirements. The sudden surfacing of this issue without any changes in our configuration or approach has left us seeking an urgent resolution.
I am hopeful a fix can be prioritized 😄
Hello - #30801 documents a similar issue, and this comment describes why default_tags
behave this way with the provided configuration (computed values, such the result of the timestamp()
function, are not supported due to limitations on how the provider is configured).
Assuming the precise apply time is not a requirement given the formatted value only includes the date portion, the plantimestamp
function could provide the desired result. This function is available in Terraform 1.5 and later. As the name suggests, its value reflects the timestamp of the plan operation, which means that during apply the value is known and avoids inclusion of a computed (unknown) value in the default_tags
block.
I was able to reproduce the issue with the original configuration, and confirm that changing the following resulted in an apply, followed by a plan with no changes.
default_tags {
tags = {
ManagedBy = "Terraform"
CreatedAt = formatdate("YYYY-MM-DD", plantimestamp())
}
}
% terraform apply -auto-approve
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
+ create
Terraform will perform the following actions:
# aws_subnet.example will be created
+ resource "aws_subnet" "example" {
<snip>
+ tags = {
+ "Name" = "my-subnet-resource"
}
+ tags_all = {
+ "CreatedAt" = "2024-02-15"
+ "ManagedBy" = "Terraform"
+ "Name" = "my-subnet-resource"
}
+ vpc_id = (known after apply)
}
# aws_vpc.example will be created
+ resource "aws_vpc" "example" {
<snip>
+ tags = {
+ "Name" = "my-vpc-resource"
}
+ tags_all = {
+ "CreatedAt" = "2024-02-15"
+ "ManagedBy" = "Terraform"
+ "Name" = "my-vpc-resource"
}
}
Plan: 2 to add, 0 to change, 0 to destroy.
aws_vpc.example: Creating...
aws_vpc.example: Creation complete after 1s [id=vpc-00d35960d803dcb4e]
aws_subnet.example: Creating...
aws_subnet.example: Creation complete after 1s [id=subnet-00e8db1d2863519e1]
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
% terraform plan
aws_vpc.example: Refreshing state... [id=vpc-00d35960d803dcb4e]
aws_subnet.example: Refreshing state... [id=subnet-00e8db1d2863519e1]
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are
needed.
% terraform -v
Terraform v1.7.3
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v5.35.0
Please let me know if I misunderstood any part of the original report given the minimal reproduction may not be reflective of the full configuration included in the screenshots. If this adjustment works for your use case, we can go ahead and close this issue out.
Thank you for the update, @jar-b!
We reviewed the comment you referenced (link to comment), but it seems there's been a misunderstanding regarding its applicability to our current issue.
The comment suggests, The following configuration will be possible in v5.0.0.
, given that our environment is running on version v5.35.0
, we naturally assumed support for dynamic values was included. However, it appears this assumption may not align with the actual functionality available in our version.
We have been experiencing a similar behavior with tags_all
being missing in the plan if we add an empty tag, exactly what is being reported in this other issue, particularly interesting is this comment.
This ticket can be closed as a duplicate, but it will be really nice to hear about the plans to address the tagging issues that @johnsonaj has mentioned.
Thanks again :)
Hey @fcastagninizoom - thanks for your feedback!
If your configuration and issue varies significantly from this one (computed tags such as a timestamp in the default_tags
block), it may be worth opening a separate issue with a minimal configuration so we can better assess how to help. If it turns out to be the same root cause as another issue, we can always link and close it as necessary.
Since it looks like this the original issue here has been addressed, and we haven't heard back, closing.
[!WARNING] This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.
Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.
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.
Terraform Core Version
1.7.3
AWS Provider Version
5.35.0
Affected Resource(s)
All resources with
tags_all
attributeExpected Behavior
All resources should have the
tags_all
attribute computed with dynamic default tags applied, reflecting global tagging configurations.Actual Behavior
The
tags_all
attribute is not consistently computed across all resources, indicating a failure to apply dynamic default tags as expected.This is another example of the inconsistent behavior
Relevant Error/Panic Output Snippet
Terraform Configuration Files
Steps to Reproduce
To reproduce the bug:
Debug Output
No response
Panic Output
No response
Important Factoids
We examined a json version of a plan and confirm that terraform is not computing the
tags_all
attribute for some resources. Other resources do have thetags_all
attribute.References
No response
Would you like to implement a fix?
None