-
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
servicecatalogappregistry: Application Manager URL as string property #23779
Comments
Thanks for your feedback, we will get this triaged and will address accordingly. |
Thank you for the feature request! @santanugho is this something you're interested in picking up still? |
…24483) When an application is created using `Application` construct, an output is automatically created in the customer defined stack without customer's intention to show related Application Manager URL for the application created. This can increase customer's CFN output usage without customer acknowledge and control. This commit: - emits the CFN Output in the AppRegistry managed stack where the application is created to allow all the stacks deployed in the cdk project to be associated to the application. Customers can control whether to emit the URL as CFN output by setting `emitApplicationManagerUrlAsOutput`. - changes `applicationManagerUrl` to a string type. Customers can create further create CFN output from this property. Closes #23779 BREAKING CHANGE: This commit contains destructive changes to the RAM Share. Since the application RAM share name is calculated by the application construct, where one property is removed. Integration test detects a breaking change where RAM share will be created. Integration test snapshot is updated to cater this destructive change. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
…ws#24483) When an application is created using `Application` construct, an output is automatically created in the customer defined stack without customer's intention to show related Application Manager URL for the application created. This can increase customer's CFN output usage without customer acknowledge and control. This commit: - emits the CFN Output in the AppRegistry managed stack where the application is created to allow all the stacks deployed in the cdk project to be associated to the application. Customers can control whether to emit the URL as CFN output by setting `emitApplicationManagerUrlAsOutput`. - changes `applicationManagerUrl` to a string type. Customers can create further create CFN output from this property. Closes aws#23779 BREAKING CHANGE: This commit contains destructive changes to the RAM Share. Since the application RAM share name is calculated by the application construct, where one property is removed. Integration test detects a breaking change where RAM share will be created. Integration test snapshot is updated to cater this destructive change. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Describe the feature
Application Manager URL as string property.
P.S.: Full service name and capitalization in the applicationManagerUrl description: "Application manager url for the application created" => "Systems Manager Application Manager URL for the application created"
Use Case
I see the library defines Application Manager URL as
CfnOutput
. I am not sure it would be a good practice, becauseCfnOutput
is part of customer-defined stack outwards facing interface. Customers usually define outputs they need, and don’t want outputs they don’t need. They might want to define output with exactly this name, and it will be an error (output name is unique in a template). Making this value accessible through construct interface will let the customer decide whether and where to make aCfnOutput
out of this.Proposed Solution
Make ApplicationManagerUrl a string instead of CfnOutput.
Other Information
No response
Acknowledgements
CDK version used
2.61.1
Environment details (OS name and version, etc.)
macOS Monterey 12.6.2
The text was updated successfully, but these errors were encountered: