Skip to content
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

fix(servicecatalogappregistry): Associate an application with attribute group #24378

Merged
merged 11 commits into from
Mar 6, 2023

Conversation

santanugho
Copy link
Contributor

Application-AttributeGroup association happens in ApplicationStack.
Therefore before the deployment of ApplicationStack, AttributeGroup stack should have been deployed.
But with ApplicationAssociator where we associate all the stacks with the application (created as a part of ApplicationAssociator), attributeGroup stack now depends upon ApplicationAssociator stack to be created (since ResourceAssociation happens inside ResourceStack).
This creates a circular dependency and hence cdk synth fails. We found this bug during internal testing
This PR address this circular dependency issue, by allowing the customers of ApplicationAssociator to associate an attribute group in attribute group stack.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@github-actions github-actions bot added repeat-contributor [Pilot] contributed between 3-5 PRs to the CDK p2 labels Feb 28, 2023
@aws-cdk-automation aws-cdk-automation requested a review from a team February 28, 2023 18:46
Copy link
Contributor

@TheRealAmazonKendra TheRealAmazonKendra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution, we cannot provide a meaningful review until there is a passing build. If you have questions about the build failure, please let us know.

Please make sure that your PR title confirms to the conventional commit standard (fix, feat, chore) and that it is written in a style that will reflect correctly in the change log (See Contributing Guide, Pull Requests). Specifically, a fix should state the bug, not the solution.

Lastly, is there an open issue for this? If so, please link it in the PR body.

@mergify mergify bot dismissed TheRealAmazonKendra’s stale review February 28, 2023 23:36

Pull request has been modified.

@TheRealAmazonKendra
Copy link
Contributor

Thanks for getting the build passing. The last two pieces of my comment will still need to be addressed.

Please make sure that your PR title confirms to the conventional commit standard (fix, feat, chore) and that it is written in a style that will reflect correctly in the change log (See Contributing Guide, Pull Requests). Specifically, a fix should state the bug, not the solution.

Lastly, is there an open issue for this? If so, please link it in the PR body.

@santanugho
Copy link
Contributor Author

Thanks for getting the build passing. The last two pieces of my comment will still need to be addressed.

Please make sure that your PR title confirms to the conventional commit standard (fix, feat, chore) and that it is written in a style that will reflect correctly in the change log (See Contributing Guide, Pull Requests). Specifically, a fix should state the bug, not the solution.

Lastly, is there an open issue for this? If so, please link it in the PR body.

PR title confirms to the conventional commit standard. This PR is for a bug fix in servicecatalogappregistry and the PR title is as per that standard.
This bug has been reported internally and there is no github issue open for it.

Comment on lines +109 to +121
class CustomAppRegistryAttributeGroup extends cdk.Stack {
public readonly attributeGroup: appreg.AttributeGroup
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const myAttributeGroup = new appreg.AttributeGroup(app, 'MyFirstAttributeGroup', {
attributeGroupName: 'MyAttributeGroupName',
description: 'Test attribute group',
attributes: {},
});

this.attributeGroup = myAttributeGroup;
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really expect people to define a stack for their AttributeGroup? Couldn't it go into one of the other stacks?

For example, wouldn't it make sense for a user to do:

const associatedApp = new appreg.ApplicationAssociator(app, 'AssociatedApplication', {
  applications: [ /* ... */],
  attributes: { 
    // ...
  },
});

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

attributes is not a valid input as per ApplicationAssociatorProps. Attribute group can definitely be a part of some other stack, however customers need to explicitly associate the attribute group to the application, as ApplicationAssociator is responsible to associate the stacks within the scope, it wont automatically associate the underlying AGs within a stack.

Copy link
Contributor

@rix0rrr rix0rrr Mar 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

attributes is not a valid input as per ApplicationAssociatorProps

I understand.

The nice thing about software is that it is not like the laws of physics. It is in fact changeable.

  • FACT: "attributes" can not be passed to the ApplicationAssociator
  • QUESTION: would it be better/easier/more convenient/more obvious IF "attributes" could be passed to ApplicationAssociator, and the creation of the AttributeGroup happens implicitly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I like this idea of including attribute-group in application-associator construct. However, can we first prioritize this bug fix which will unblock our customers and they should be able to associate an attribute group to an application.

I will do some more deep dive on including attribute-group in application-associator, its pros and cons and will let you know about our plan to modify application-associator in order to include attribute-group.

Let me know if this plan works for you.

Comment on lines 238 to 240
declare const application: appreg.Application;
declare const attributeGroup: appreg.AttributeGroup;
attributeGroup.associateApplicationWithAttributeGroup(application);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good, although the method name is a little long. Given that the subject is of type AttributeGroup and the object is of type Application, do you really think we need the words "Application" and "AttributeGroup" in the method name?

Why not

attributeGroup.associate(application);
// or
attributeGroup.associateWith(application);
// or
attributeGroup.associateTo(application);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah associateWith makes a lot more sense. Changed the same in the latest version.

rix0rrr
rix0rrr previously requested changes Mar 2, 2023
Copy link
Contributor

@rix0rrr rix0rrr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my previous comment: do we want to force the user to create an attributegroup themselves?

I think users would prefer to minimize the amount of stacks in their account if possible.

@mergify mergify bot dismissed rix0rrr’s stale review March 3, 2023 17:41

Pull request has been modified.

@mergify
Copy link
Contributor

mergify bot commented Mar 6, 2023

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-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: a329869
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify mergify bot merged commit d1264c1 into aws:main Mar 6, 2023
@mergify
Copy link
Contributor

mergify bot commented Mar 6, 2023

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).

homakk pushed a commit to homakk/aws-cdk that referenced this pull request Mar 28, 2023
…te group (aws#24378)

`Application-AttributeGroup` association happens in `ApplicationStack`. 
Therefore before the deployment of `ApplicationStack`, `AttributeGroup` stack should have been deployed. 
But with `ApplicationAssociator `where we associate all the stacks with the application (created as a part of `ApplicationAssociator`), attributeGroup stack now depends upon `ApplicationAssociator` stack to be created (since ResourceAssociation happens inside ResourceStack).
This creates a circular dependency and hence cdk synth fails. We found this bug during internal testing
This PR address this circular dependency issue, by allowing the customers of `ApplicationAssociator` to associate an attribute group in attribute group stack.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p2 repeat-contributor [Pilot] contributed between 3-5 PRs to the CDK
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants