Open mkielar opened 1 year ago
Voting for Prioritization
Volunteering to Work on This Issue
It's weird...
aws_appautoscaling_policy
resource. In that template, one of the resources got updated and went silent, and the other keeps showing changes on tags_all
.aws_appautoscaling_policy
resource. In that template, also one of the resources got updated and went silent, and remaining 9 pop up showing tags_all
changes.What's going on there?
I ran into this today, as well.
According to the note at the top of the latest doc for aws_appautoscaling_target
:
NOTE:
Scalable targets created before 2023-03-20 may not have an assigned arn. These resource cannot use tags or
participate in default_tags. To prevent terraform plan showing differences that can never be reconciled, use the
[lifecycle.ignore_changes](https://developer.hashicorp.com/terraform/language/meta-arguments
/lifecycle#ignore_changes) meta-argument. See the example below.
Hopefully this answers your question, as it did for me😄
But of course, when I try to use the lifecycle meta-arg (like in the specified example), Terraform throws:
Error: Unsupported attribute
This object has no argument, nested block, or exported attribute named "tags_all".
Maybe I'll try using an older version of the provider.
Update: Using version 4.65.0 of the provider alleviated this issue for me, so if you don't need any specific features of 4.66+, this might be easiest workaround for now.
Okay, so that's what was causing this weird behaviour. Some of the instances of aws_appautoscaling_target
were old, and some new. I have verified this by running:
terraform state list | grep aws_appautoscaling_target
and then
terraform state show <address>
for all listed addresses of app_autoscaling_targets
, and seeing that some of the indeed don't have ARN
s, and that these are the same that keep popping up in terraform plan
s.
To work around this, I decided to re-create them and see what happens. So I made them all tainted with:
for addr in $(terraform state list | grep -E "aws_appautoscaling_(target|policy)"); do terraform taint "${addr}"; done
and then ran terraform apply
. Note that I had to mark both target
and policy
resources as tainted to make terraform aware all of them need to be replaced. Not having done that, terraform would only recreate the target
s and not notice that AWS implicitly deleted all the policies
(they would pop up as "will be created" on next terraform apply
but for the period between I'd not have a working autoscaling...).
After that terraform plan
s are back to normal.
The only issue with that workaround is that I now have ~40 git repos with terraform templates, times 4 environment statefiles per repository and would have to taint these resources in all of them. Oh joy...
I had the same problem and confirmed that a terraform taint
cycle fixed it for resources which were created years ago. That process is functional but given the performance of the app.terraform.io service it takes about a minute per resource to update the state files.
I'd say it's caused by https://github.com/hashicorp/terraform-provider-aws/pull/31214 cc @ewbankkit
we might need some more tweaks for default_tags
Can confirm that this is still an issue on provider version 5.7.0
Okay, so that's what was causing this weird behaviour. Some of the instances of
aws_appautoscaling_target
were old, and some new. I have verified this by running:terraform state list | grep aws_appautoscaling_target
and then
terraform state show <address>
for all listed addresses of
app_autoscaling_targets
, and seeing that some of the indeed don't haveARN
s, and that these are the same that keep popping up interraform plan
s.To work around this, I decided to re-create them and see what happens. So I made them all tainted with:
for addr in $(terraform state list | grep -E "aws_appautoscaling_(target|policy)"); do terraform taint "${addr}"; done
and then ran
terraform apply
. Note that I had to mark bothtarget
andpolicy
resources as tainted to make terraform aware all of them need to be replaced. Not having done that, terraform would only recreate thetarget
s and not notice that AWS implicitly deleted all thepolicies
(they would pop up as "will be created" on nextterraform apply
but for the period between I'd not have a working autoscaling...).After that
terraform plan
s are back to normal.The only issue with that workaround is that I now have ~40 git repos with terraform templates, times 4 environment statefiles per repository and would have to taint these resources in all of them. Oh joy...
similar to this approach but i used terraform apply -replace
terraform apply -replace="aws_appautoscaling_target.my_target"
any plans to fix this?
I tried to use terraform taint
on these resource to create new ones. But unfortunately, that resulted in me running into https://github.com/hashicorp/terraform-provider-aws/issues/31839
I noticed in the appautoscaling_target
documentation it gives a workaround for this problem:
Scalable targets created before 2023-03-20 may not have an assigned
arn
. These resource cannot usetags
or participate indefault_tags
. To preventterraform plan
showing differences that can never be reconciled, use the lifecycle.ignore_changes meta-argument. See the example below.
resource "aws_appautoscaling_target" "ecs_target" {
service_namespace = "rds"
scalable_dimension = "rds:cluster:ReadReplicaCount"
resource_id = "cluster:${aws_rds_cluster.aurora_pph_cluster.id}"
min_capacity = 1
max_capacity = 4
lifecycle {
ignore_changes = [
tags_all,
]
}
}
This workaround worked for me. :heavy_check_mark:
Terraform Core Version
1.4.2
AWS Provider Version
4.66.1
Affected Resource(s)
aws_appautoscaling_target
Expected Behavior
After
terraform apply
,terraform plan
should stop showing changes intags_all
attribute.Actual Behavior
terraform plan
keeps showing this change afterterraform apply
has already been applied on this change:Relevant Error/Panic Output Snippet
No response
Terraform Configuration Files
The resource:
Provider configuration
tags
variable is set up as follows:Steps to Reproduce
terraform plan
after upgrading from4.65
to4.66.1
, and observe the change intags_all
terraform apply
- it seems to be updating the resource.terraform plan
again, and observe the change intags_all
pops up again.Debug Output
No response
Panic Output
No response
Important Factoids
No response
References
No response
Would you like to implement a fix?
None