terraform-provider-aws
terraform-provider-aws copied to clipboard
StackSet with auto_deployment gets administration_role_arn during refresh, resulting in update loop
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 v1.1.2
- provider aws v3.70.0
Affected Resource(s)
- aws_cloudformation_stack_set
Terraform Configuration Files
Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
resource "aws_cloudformation_stack_set" "stacksetOU" {
count = var.OUs == null || !var.migrate ? 0 : 1
auto_deployment {
enabled = true
retain_stacks_on_account_removal = false
}
name = var.name
permission_model = "SERVICE_MANAGED"
template_body = var.template_body
parameters = var.parameters
capabilities = var.capabilities
tags = var.tags
timeouts {
update = var.update
}
}
Debug Output
Panic Output
Expected Behavior
There were no changes to the stack itself, so not update needed
Actual Behavior
The stackset is updated successfully, only to planned for update on the next run again.
This is the plan, showing that the administrator_role_arn will be removed (as it is service managed, it should not be there) The update is successful when i check in the AWS Console Organizations
Terraform will perform the following actions:
# module.BASELINE.aws_cloudformation_stack_set.stacksetOU[0] will be updated in-place
~ resource "aws_cloudformation_stack_set" "stacksetOU" {
- administration_role_arn = "arn:aws:iam::11111111111:role/aws-service-role/stacksets.cloudformation.amazonaws.com/AWSServiceRoleForCloudFormationStackSetsOrgAdmin" -> null
id = "BASELINE"
name = "BASELINE"
Steps to Reproduce
Important Factoids
When i do add the administrator_role_arn to the configuration, just so it matches the state, i get this expected error
1: resource "aws_cloudformation_stack_set" "stacksetOU" {
"auto_deployment": conflicts with administration_role_arn
References
- #0000
Hey @fvant 👋 Thank you for taking the time to raise this! So that we have all of the necessary information in order to look into this, can you supply an example Terraform configuration as well? I'm not positive as to whether the engineer who looks at this will need debug logs or not for this one, but that may be something that we end up requesting as well.
Hi @justinretzolk , this is an issue I am also having with Terraform deployments at the moment. I would like to point out that I think this is part of a much wider problem with Terraform's AWS Provider implementation of AWS CloudFormation Stacksets.
In my instance, when Terraform attempts to deploy a second time because of this issue, it causes a much wider failure because other parameters cannot be configured such as FailureTolerance and MaxConcurrent (which stops timeout issues when deploying) detailed here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html#stackset-ops-options.
The wider issues related are linked here and the only solution I have had is to avoid using SERVICE_MANAGED roles and make use of provisioners :( so I configure the required StackSet options.
https://github.com/hashicorp/terraform-provider-aws/issues/11380 https://github.com/hashicorp/terraform-provider-aws/issues/18490 https://github.com/hashicorp/terraform-provider-aws/issues/12877
I have noticed that you have commented on these so it would be great to get a much wider update to the issues present! Thanks
Terraform version: 1.1.5 AWS Provider version: 4.3.0
@fvant @justinretzolk Any updates on this?
Hey @ReadyElbow 👋 Thank you for checking in on this. Unfortunately, I'm not able to provide an estimate on when this will be looked into due to the potential of shifting priorities. We prioritize work by count of ":+1:" reactions, as well as a few other things. A larger prioritization document is in the works, but in the meantime additional information may be found in our issue lifecycle document.
Looks like we're running into this. Not sure if this would work - but potentially a workaround here is to add:
lifecycle {
ignore_changes = [
administration_role_arn
]
}
Subscribing because I'm running into the same issue, going to look into @rayterrill tip. Thanks!
left a thumbs up. Running into exactly the same issue when trying to deploy a service_managed stackset
Same problem here. Adding the lifecycle rule is a great work around.
Can confirm my org runs into this same issue - adding a lifecycle rule works as a workaround for now.
the lifecycle rule works for now
can also confirm running into this same issue - adding a lifecycle rule works as a workaround for now. any updates on this eventually?