fix(servicecatalogappregistry): applicationName can not be changed after deployment #24409
Conversation
github-actions
bot
added
p2
repeat-contributor
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
rix0rrr
changed the title
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…ter deployment (aws#24409) Background: * Customers wish to control or modify the stack id of the Application stack to follow their project conventions within CDK. * In previous [fix](aws#24171), we had deprecated the stack id to push users towards using stack name as the main mechanism for stack identification. * Default stack name as per this [fix](aws#24171) has `Application Name` embedded in it. If customers wants to **update the application name**, then a new stack name as well as new stack id will be generated, which will eventually create a new Application in a new stack. Problem: * Application associator associates all stacks in scope to an application. * With `ApplicationName` in stack name, we will create an application within a stack. When customers attempt to update the name of the application, we will create a new stack and eventually create a new application, which is the first problem. * In this new application within the new stack, we will try to associate all stacks within the `app` scope, which is already associated to the original application in the original stack and hence cannot be further associated to the new application which will make the deployment of the stack with updated name fail. Fix: * We will continue to honor customer provided stack Name. * If no stack name is provided, then we will default it to `ApplicationAssociator-${hashValues(scope.node.addr)}-Stack`, which doesnt contain `Application Name`. Related Links: * Previous PR which introduced this bug: aws#24171 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Background:
Application Nameembedded in it. If customers wants to update the application name, then a new stack name as well as new stack id will be generated, which will eventually create a new Application in a new stack.Problem:
ApplicationNamein stack name, we will create an application within a stack. When customers attempt to update the name of the application, we will create a new stack and eventually create a new application, which is the first problem.appscope, which is already associated to the original application in the original stack and hence cannot be further associated to the new application which will make the deployment of the stack with updated name fail.Fix:
ApplicationAssociator-${hashValues(scope.node.addr)}-Stack, which doesnt containApplication Name.Related Links:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license