StackSet with auto_deployment gets administration_role_arn during refresh, resulting in update loop

[fvant]

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

[justinretzolk]

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.

[ReadyElbow]

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.

#11380
#18490
#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

[ReadyElbow]

@fvant @justinretzolk
Any updates on this?

[justinretzolk]

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.

[rayterrill]

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
    ]
  }

[KarlCF]

Subscribing because I'm running into the same issue, going to look into @rayterrill tip. Thanks!

[Kimnor]

left a thumbs up. Running into exactly the same issue when trying to deploy a service_managed stackset

[brycelowe]

Same problem here. Adding the lifecycle rule is a great work around.

[acoppolawb]

Can confirm my org runs into this same issue - adding a lifecycle rule works as a workaround for now.

[josjaf]

the lifecycle rule works for now

[rauschbit]

can also confirm running into this same issue - adding a lifecycle rule works as a workaround for now.
any updates on this eventually?