hashicorp / terraform-provider-aws

The AWS Provider enables Terraform to manage AWS resources.
https://registry.terraform.io/providers/hashicorp/aws
Mozilla Public License 2.0
9.72k stars 9.08k forks source link

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

Open fvant opened 2 years ago

fvant commented 2 years ago

Community Note

Terraform CLI and Terraform AWS Provider Version

Affected Resource(s)

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

justinretzolk commented 2 years ago

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 commented 2 years ago

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

ReadyElbow commented 2 years ago

@fvant @justinretzolk Any updates on this?

justinretzolk commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Kimnor commented 1 year ago

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

brycelowe commented 1 year ago

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

acoppolawb commented 1 year ago

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

josjaf commented 1 year ago

the lifecycle rule works for now

rauschbit commented 3 months ago

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