-
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
(servicecatalog): TagOptions cannot be shared among portfolios in the same account #17753
Comments
Thanks for detailed issue. You're correct that currently we don't surface |
We will be implementing |
Fixes: [#17753](#17753) Previously TagOptions were defined via an interface and we only created the underlying resources upon an association. This broke CX if tagoptions were mangaged centrally. We move to make the TagOptions class a wrapper around aggregate individual TagOptions. BREAKING CHANGE: `TagOptions` now have `scope` and `props` argument in constructor, and data is now passed via a `allowedValueForTags` field in props ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Fixes: [aws#17753](aws#17753) Previously TagOptions were defined via an interface and we only created the underlying resources upon an association. This broke CX if tagoptions were mangaged centrally. We move to make the TagOptions class a wrapper around aggregate individual TagOptions. BREAKING CHANGE: `TagOptions` now have `scope` and `props` argument in constructor, and data is now passed via a `allowedValueForTags` field in props ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Fixes: [aws#17753](aws#17753) Previously TagOptions were defined via an interface and we only created the underlying resources upon an association. This broke CX if tagoptions were mangaged centrally. We move to make the TagOptions class a wrapper around aggregate individual TagOptions. BREAKING CHANGE: `TagOptions` now have `scope` and `props` argument in constructor, and data is now passed via a `allowedValueForTags` field in props ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
What is the problem?
Specifying TagOptions and sharing them with two separate ServiceCatalog portfolios in different stacks in the same AWS account will fail because it leads to a duplicate creation of TagOption resources (they are created alongside the TagOptionAssocation).
Reproduction Steps
What did you expect to happen?
I expected the TagOptions class to implement the Construct interface so that TagOptions would be created and that passing the TagOptions class to a portfolio would only create the assocations. For my use case I'll simple add the portfolios in one stack. However I can imagine in other teams, where portfolios are created by different teams, this would not be possible. Or we'd need to resort to the L1 classes.
What actually happened?
The code will synthesize, but the deployment will fail when the second portfolio is being deployed, because the TagOption already exists in the first Portfolio stack. The TagOptions in the TagOptionsStack will not create TagOption in that stack, since the TagOptions class is not a construct.
CDK CLI Version
1.122.0 (build ae09c16)
Framework Version
No response
Node.js Version
v16.13.0
OS
Fedora
Language
Typescript
Language Version
TypeScript (3.9.7)
Other information
No response
The text was updated successfully, but these errors were encountered: