Resource aws_serverlessapplicationrepository_cloudformation_stack is failing during update

[himsharma01]

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

Description

While calling cloudformation stack via AWS Terraform resource. On first "terraform apply", it gets created successfully and when I run "terraform apply" again without any changes it fails. I'm not sure if there are no changes then why CF is creating a change stack and failing it.

Terraform CLI and Terraform AWS Provider Version

Terraform v1.0.4
on darwin_amd64

terraform providers
Providers required by configuration:
├── provider[registry.terraform.io/hashicorp/aws] >= 4.0.0
└── provider[registry.terraform.io/sumologic/sumologic] >= 2.10.0

Affected Resource(s)

• aws_serverlessapplicationrepository_cloudformation_stack

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

data "aws_serverlessapplicationrepository_application" "app" {
  application_id   = "arn:aws:serverlessrepo:us-east-1:956882708938:applications/sumologic-s3-logging-auto-enable"
  semantic_version = "1.0.2"
}

resource "aws_serverlessapplicationrepository_cloudformation_stack" "auto_enable_access_logs" {

  name             = "Auto-Enable-Access-Logs-Elb"
  application_id   = "arn:aws:serverlessrepo:us-east-1:956882708938:applications/sumologic-s3-logging-auto-enable"
  semantic_version = "1.0.2"
  capabilities     = data.aws_serverlessapplicationrepository_application.app.required_capabilities
  parameters = {
    BucketName                = "xxx"
    BucketPrefix              = "elasticloadbalancing"
    AutoEnableLogging         = "ALB"
    AutoEnableResourceOptions = var.auto_enable_access_logs
    FilterExpression          = var.auto_enable_access_logs_options.filter
    RemoveOnDeleteStack       = var.auto_enable_access_logs_options.remove_on_delete_stack
  }
}

Debug Output

# aws_serverlessapplicationrepository_cloudformation_stack.auto_enable_access_logs will be updated in-place
  ~ resource "aws_serverlessapplicationrepository_cloudformation_stack" "auto_enable_access_logs" {
        id               = "arn:aws:cloudformation:us-east-1:205654718605:stack/serverlessrepo-Auto-Enable-Access-Logs-Elb/21f1b5c0-a376-11ec-b5df-0e8bbe18c713"
        name             = "Auto-Enable-Access-Logs-Elb"
      ~ parameters       = {
          + "AutoEnableResourceOptions" = "Both"
          + "FilterExpression"          = ""
          + "RemoveOnDeleteStack"       = "true"
            # (3 unchanged elements hidden)
        }
        tags             = {}
        # (5 unchanged attributes hidden)
    }
Plan: 0 to add, 1 to change, 0 to destroy.


aws_serverlessapplicationrepository_cloudformation_stack.auto_enable_access_logs: Modifying... [id=arn:aws:cloudformation:us-east-1:205654718605:stack/serverlessrepo-Auto-Enable-Access-Logs-Elb/21f1b5c0-a376-11ec-b5df-0e8bbe18c713]
aws_serverlessapplicationrepository_cloudformation_stack.auto_enable_access_logs: Still modifying... [id=arn:aws:cloudformation:us-east-1:205654...b/21f1b5c0-a376-11ec-b5df-0e8bbe18c713, 10s elapsed]
aws_serverlessapplicationrepository_cloudformation_stack.auto_enable_access_logs: Still modifying... [id=arn:aws:cloudformation:us-east-1:205654...b/21f1b5c0-a376-11ec-b5df-0e8bbe18c713, 20s elapsed]
│ Error: error creating Serverless Application Repository CloudFormation Stack (arn:aws:cloudformation:us-east-1:205654718605:stack/serverlessrepo-Auto-Enable-Access-Logs-Elb/21f1b5c0-a376-11ec-b5df-0e8bbe18c713) change set: unexpected state 'FAILED', wanted target 'CREATE_COMPLETE'. last error: No updates are to be performed.
│ 
│   with aws_serverlessapplicationrepository_cloudformation_stack.auto_enable_access_logs,
│   on [poc.tf](http://poc.tf/) line 6, in resource "aws_serverlessapplicationrepository_cloudformation_stack" "auto_enable_access_logs":
│    6: resource "aws_serverlessapplicationrepository_cloudformation_stack" "auto_enable_access_logs" {
│

Expected Behavior

If there is no change in configuration, then terraform should not show Plan: 0 to add, 1 to change, 0 to destroy. instead ignore and apply the intentional changes.

Actual Behavior

On first "terraform apply", it gets created successfully and when I run "terraform apply" again without any changes it fails. I'm not sure if there are no changes then why CF is creating a change stack and failing it. Or it should fail gracefully and apply other changes. Because of this bug we are not able to make any modifications in our infra as its always failing at same point and not able to proceed once it is interrupted.

Please note we can not do hardcoding on above passed variables as they need to be dynamic as per code.

Steps to Reproduce

1. Copy above code
2. terraform apply
3. Run terraform apply

References

#16485

• Using the aws_serverlessapplicationrepository_cloudformation_stack resource works the first time, but subsequent updates fail. #16485

[justinretzolk]

Hey @himsharma01 👋 Thank you for taking the time to raise this! I see that you've linked #16485 -- on a quick read, this issue appears to be a duplicate of that issue. Is there anything that I'm not catching that would indicate that this isn't a duplicate of that issue?

[himsharma01]

Hey @justinretzolk , The resolution provided there was hardcoding the values but we cannot hardcode in our code. Or Please let me know the resolution if I have misread #16485 resolution and give me correct pointers.
Re-iterating problem here again - I'm not sure why this resource is not able to store values of "var.auto_enable_access_logs" (as specified in our code above) and on each subsequent terraform apply(s) , it detects it as change and creates a stack-set.

[justinretzolk]

Hey @himsharma01 👋 I believe your read of the issue was correct. My reason for asking was less than the linked issue would resolve the issue (it's still an open issue that needs to be worked on), and more determining whether or not your issue was a duplicate of the linked issue. We typically try to keep multiple reports of the same bug contained to a single GitHub issue to limit the spread of potentially helpful information. To ask another way, would you be okay with me merging this issue into the other, as you seem to have reported the same bug here?

[himsharma01]

Hey @justinretzolk , The old issue is 2 years old and still open, I'm afraid if we merge it to old issue it might again get lost again and we will not be able to reach to a solution on this issue. However please proceed as per your polices but I just want to make sure we should be able to zero'ed in on this issue as its pending from a long time.

[justinretzolk]

Hey @himsharma01 -- I appreciate your understanding here, and absolutely understand where you're coming from in not wanting this issue to get lost. We use ":+1:" reactions to help with prioritization, and given that the linked issue currently has more than yours, merging the issues is more likely to help than hurt in this case. With that in mind, we'll close this in favor of the original issue so that we can continue to track that one for prioritization. If you've not already, I'd recommend adding a 👍 reaction to that issue as well, to help to boost its numbers.

[github-actions]

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.