-
Notifications
You must be signed in to change notification settings - Fork 4k
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(ecs): support ecs tag propagation and ecs managed tags #3420
Conversation
@pkandasamy91 please review |
@iamhopaul123 looks like the integration tests need to be updated as well. |
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.
Please add unit tests to verify that this works as expected and update integration tests to reflect this change.
Done! |
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 PR seems to introduce behavior-breaking changes, which is undesirable. We can discuss whether this has the potential to actually break users, or if the new behavior is functionally compatible, but my instinct right now is that we should preserve the current behavior.
Also, I couldn't find documentation for the CFN properties that you are now wiring, so I couldn't assess the validity of certain default behaviors (but I suspect they're not what I'll want, because they turn into breaking behavior).
@@ -41,6 +41,8 @@ export = { | |||
DesiredCount: 1, | |||
LaunchType: LaunchType.FARGATE, | |||
LoadBalancers: [], | |||
EnableECSManagedTags: true, | |||
PropagateTags: PropagateTagsFromType.SERVICE, |
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 fact you had to introduce these means you're making a breaking change. We don't want that.
@RomainMuller after talking with my teammates, we think that it would not be causing breaking changes for adding default values for those two Service properties. Because from the customers' perspective they don't have a reason for not needing those ECS managed tag. However, we agree we should add "no_propagate" option for those who don't want to propagate tags to tasks. |
87207a7
to
23f5b2e
Compare
@eladb do you have any thoughts on this? Should this be considered a breaking change? |
Pull Request Checklist
|
Pull Request Checklist
|
Pull request has been modified.
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.
Looks good overall, had a couple comments.
packages/@aws-cdk/aws-ecs-patterns/test/fargate/integ.asset-image.expected.json
Outdated
Show resolved
Hide resolved
Codebuild (Continuous Integration) build failed for current commits. Please check log and resolve before PR is merged. |
Tests are failing, try to remove the empty ServiceRegistries and LoadBalancers properties. I think it's related to an error in resolving the merge conflicts. |
Pull request has been modified.
packages/@aws-cdk/aws-codepipeline-actions/test/integ.pipeline-ecs-deploy.expected.json
Outdated
Show resolved
Hide resolved
Pull request has been modified.
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.
LGTM
Thank you for contributing! Your pull request is now being automatically merged. |
Add two properties for ECS Service to support ECS tag propagation and ECS managed tags.
Please read the contribution guidelines and follow the pull-request checklist.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license