-
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
feat(servicecatalogappregistry): add attribute groups to an application #24672
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
packages/@aws-cdk/aws-servicecatalogappregistry/lib/application.ts
Outdated
Show resolved
Hide resolved
/** | ||
* Enforces a particular physical attribute group name. | ||
*/ | ||
readonly attributeGroupName: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not optional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attribute group name is the key to calculate attribute group construct id to make sure that multiple addAttributeGroup
calls won't generate the same construct ID. Since name is unique, if addAttributeGroup
is called twice with the same attributeGroupName
, construct duplicate error will be thrown. Both Names.uniqueNodeId()
and Names.uniqueResourceName()
generate id from the path of the construct, i.e. path of the application. As a result, two addAttributeGroup
calls with different names\attributes\descriptions generate two AttributeGroup
constructs with the same construct ID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be required even if we use customer provided construct id for attribute group.
Attribute group name is the key human readable identifier our service offers for customer to find the attribute group, we want to make it explicit, so that it will can make use of the name to look for the attribute group in other platforms like console or SDK client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are aware that 99% of other constructs allow the user to not specify a name and have the system one generate for them?
I don't fully understand this. What is the actual user impact (will it block deployments, interrupt cross-account access for a couple of minutes, what?), and do you think the resource replacement is reasonable behavior? |
I agree that resource replacement is not reasonable behavior, I would like to resolve this as a followup. The issue we are face is the same as |
f91fd5e
to
2167bf5
Compare
…group to the application. <body> Testing done ------------------------------------- * Related items ------------------------------------ * SIM/auto-cut ticket
<body> Testing done ------------------------------------- * Related items ------------------------------------ * SIM/auto-cut ticket
<body> Testing done ------------------------------------- * Related items ------------------------------------ * SIM/auto-cut ticket
<body> Testing done ------------------------------------- * Related items ------------------------------------ * SIM/auto-cut ticket
Change Attribute Group construct ID generation from attribute group name. Change ApplicationAssociator application to a getter. Remove logical ID from addAttributeGroup props. <body> Testing done ------------------------------------- * Related items ------------------------------------ * SIM/auto-cut ticket
…nstruct id. <body> Testing done ------------------------------------- * Related items ------------------------------------ * SIM/auto-cut ticket
<body> Testing done ------------------------------------- * Related items ------------------------------------ * SIM/auto-cut ticket
<body> Testing done ------------------------------------- * Related items ------------------------------------ * SIM/auto-cut ticket
2167bf5
to
07c0a1e
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
/** | ||
* Enforces a particular physical attribute group name. | ||
*/ | ||
readonly attributeGroupName: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are aware that 99% of other constructs allow the user to not specify a name and have the system one generate for them?
attributes: props.attributes, | ||
description: props.description, | ||
}); | ||
new CfnAttributeGroupAssociation(this, `AttributeGroupAssociation${this.generateUniqueHash(attributeGroup.node.addr)}`, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
node.addr
is already a hash :)
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). |
… to Application (#24760) `Application.shareApplication` can be called multiple times which generates different resources within the same `Application` construct. The share construct id generation was based on child length of `Application` construct. This makes every change to the `Application` construct can unnecessarily replace the RAM share when the share actually needs no update. Similar to the solution for `addAttributeGroup` introduced in the [previous update](#24672), this commit starts to require both construct id and share name in the `Application.shareApplication` method input, which are used to create RAM share construct. For `ApplicationAssociator`, `Application.shareApplication` is called for cross-account stack associations. Share construct id depends on the node unique id of the application in `ApplicationAssociator` and the node unique id of the stack to be associated. This reduces unnecessary share replacement in `ApplicationAssociator` stack. BREAKING CHANGE: This commit involves share replacement during the deployment of `ApplicationAssociator` due to share construct id update. After this change, frequent share replacements due to structural change in `Application` construct should be avoided. `Application.shareApplication` starts to require construct id (first argument) and share name (added in `ShareOption`) as input. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…on (aws#24672) To associate a attribute group to an application created in `ApplicationAssociator`, customers have to use `AttributeGroup` construct separately to create and associate the attribute group separately. This makes the `AttributeGroup` and `AttributeGroupAssociation` created in another stack than `ApplicationAssociator` stack. This commits provides an one-stop action, i.e. `Application.addAttributeGroup()`, to create and associate attribute group on `Application` Construct. This solution not only makes attribute group creation and association easier for customer who uses `Application` construct, but also lets customer to have attribute groups and attribute group associations for the `ApplicationAssociator` applications in the same stack. `Application.addAttributeGroup()` has `id` in the parameters, for two reasons: - consistent with the experience where customer can define logical ID when using `new AttributeGroup()` - complexity of deciding logical ID from the attribute group input: - We have to make sure update attributes/description won't trigger create and then delete but update, which will cause name conflict exception. - We also don't want to generate logical ID from attribute group name only, as if two `Application.addAttributeGroup()` method calls with the same name will result in construct ID conflict. This exposes implementation details and makes it hard to customers to debug and resolve. 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 method is added. 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*
… to Application (aws#24760) `Application.shareApplication` can be called multiple times which generates different resources within the same `Application` construct. The share construct id generation was based on child length of `Application` construct. This makes every change to the `Application` construct can unnecessarily replace the RAM share when the share actually needs no update. Similar to the solution for `addAttributeGroup` introduced in the [previous update](aws#24672), this commit starts to require both construct id and share name in the `Application.shareApplication` method input, which are used to create RAM share construct. For `ApplicationAssociator`, `Application.shareApplication` is called for cross-account stack associations. Share construct id depends on the node unique id of the application in `ApplicationAssociator` and the node unique id of the stack to be associated. This reduces unnecessary share replacement in `ApplicationAssociator` stack. BREAKING CHANGE: This commit involves share replacement during the deployment of `ApplicationAssociator` due to share construct id update. After this change, frequent share replacements due to structural change in `Application` construct should be avoided. `Application.shareApplication` starts to require construct id (first argument) and share name (added in `ShareOption`) as input. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
To associate a attribute group to an application created in
ApplicationAssociator
, customers have to useAttributeGroup
construct separately to create and associate the attribute group separately. This makes theAttributeGroup
andAttributeGroupAssociation
created in another stack thanApplicationAssociator
stack.This commits provides an one-stop action, i.e.
Application.addAttributeGroup()
, to create and associate attribute group onApplication
Construct. This solution not only makes attribute group creation and association easier for customer who usesApplication
construct, but also lets customer to have attribute groups and attribute group associations for theApplicationAssociator
applications in the same stack.Application.addAttributeGroup()
hasid
in the parameters, for two reasons:new AttributeGroup()
Application.addAttributeGroup()
method calls with the same name will result in construct ID conflict. This exposes implementation details and makes it hard to customers to debug and resolve.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 method is added. 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