-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@aws-cdk/aws-servicecatalogappregistry-alpha: ApplicationAssociator's hardcoded stack id is not meaningful and causes conflicts if user deploys multiple apps in the same account-region #23861
Comments
Thanks for working with us on the PR for this 🙂 |
…and causes conflict when multiple stacks deployed to the same account-region (#23823) - Replace stage association error with warning - Deprecate `stackId` in TargetApplication options - Provide a default dynamic stack name for CreateTargetApplication stack with a reference to the application name - Provide a default dynamic stack name for ExistingTargetApplication stack with a reference to the application ID This fixes: [23861](#23861) Note: With this change to `stackName`, you may run into the following error during deployment if you have been using the default stack id and name by not explicitly setting them. ``` Resource handler returned message: "You already own an application 'MyApplicationName' (Service: ServiceCatalogAppRegistry, Status Code: 409, Request ID: xxxx)" (RequestToken: yyyy, HandlerErrorCode: InvalidRequest) ``` To address this error, explicitly set the `stackName` value to the name of your existing stack. For example: ```typescript const associatedApp = new ApplicationAssociator(app, 'MyApplicationAssociator', { applications: [ TargetApplication.createApplicationStack({ applicationName: 'MyApplicationName', stackName: 'ApplicationAssociatorStack', // add your existing stack name here ... ``` ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Construct Runtime Dependencies: * [ ] This PR adds new construct runtime dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-construct-runtime-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
@jungle-amazon @peterwoodworth deprecating stack ID breaks the behavior of user being able to control stack ID in AWS CDK Toolkit output. This is important for project naming convention and avoid surprising output. Using Stack ID I can set the AppRegistry application stack ID based on my project convention (UserManagementBackendApplication):
Removing Stack ID and using stack name generates a surprising name (from user perspective):
Now that TargetApplication uses cdk.App as scope (#22973), using stack name as stack ID should address this issue. Do you want me to open a separate issue for this? |
Yes, please create a separate github issue to so that we can track your issue. If I understand correctly, the new stack name references the application name which was part of the last fix, but in your use case you need stack id to have this default value as well, not just the stack name. Additionally, the user might want to customize stack ID for easier identification in CDK Toolkit interactions, not just being limited to stack name modification. We can look into this change. |
@jungle-amazon thanks for circling back! I opened the issue to clarify the ask: #24160 |
…ack name for Application stack (#24171) * Assign value of `stackName` to `stackId` for Application stack, so the stack id will always be the same as stack name. Users wanting to control stack id can do so via `stackName`. Closes #24160. Background: * Customers wish to control or modify the stack id of the Application stack to follow their project conventions within CDK. * In previous [fix](#23823), we had deprecated the stack id to push users towards using stack name as the main mechanism for stack identification. Note on backward-compatibility: After this change, the `stackId` parameter can no longer be used to control the application stack id. The stack id will always match stack name, and the default stack name if not specified will be `Application-${APPLICATION_IDENTIFIER}-Stack`. `${APPLICATION_IDENTIFIER}` is application name for CreateTargetApplication and application id for ExistingTargetApplication. If you created an application stack prior to aws-cdk [release v2.64.0](https://github.com/aws/aws-cdk/releases/tag/v2.64.0) and did not specify a stack id or name, you may run into the following error during deployment due to the creation attempt of a new stack with the same application: ```log Resource handler returned message: "You already own an application 'MyApplicationName' (Service: ServiceCatalogAppRegistry, Status Code: 409, Request ID: xxxx)" (RequestToken: yyyy, HandlerErrorCode: InvalidRequest) ``` To address this error, you can set the `stackName` value to match your existing stack. For example: ```typescript const associatedApp = new ApplicationAssociator(app, 'MyApplicationAssociator', { applications: [ TargetApplication.createApplicationStack({ applicationName: 'MyApplicationName', stackName: 'ApplicationAssociatorStack', // Add your existing stack name here ... ``` This will result in the existing stack deploying with the previous name, and the id in CDK will reflect this same stack name. Related links: * Previous PR: #23823 * Previous GitHub issue: #23861 * Original reason that introduced `stackId`: #22508 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Describe the bug
Note from user:
In addition, if a stage is not associated then currently an error is thrown. A warning should be displayed instead to continue with the rest of the child nodes, instead of stopping on the error.
Expected Behavior
Current Behavior
ApplicationAssociatorStack
because the stack ID is hardcoded to that value (if stack name is not specified by the user then the stack id is used as the name).ApplicationAssociatorStack
also doesn't provide meaningful details.Reproduction Steps
Sample code using the
ApplicationAssociator
to create a new application namedNewApplication
:Run CDK synthesis on this, and note that the stack name is
ApplicationAssociatorStack
Possible Solution
Additional Information/Context
No response
CDK CLI Version
2.50.0
Framework Version
No response
Node.js Version
16.5.0
OS
macOS 12.6.2 Monterey
Language
Typescript
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: