fix(ecs-patterns): feature flag missing for breaking change passing container port for target group port#20284
Merged
mergify[bot] merged 2 commits intomasterfrom May 12, 2022
Conversation
|
|
rix0rrr
approved these changes
May 12, 2022
| * | ||
| * This is a feature flag because updating `Port` causes a replacement of the target groups, which is a breaking change. | ||
| */ | ||
| export const ECS_PATTERNS_TARGET_GROUP_PORT_FROM_COTAINER_PORT = '@aws-cdk/aws-ecs-patterns:containerPortToTargetGroupPort'; |
Contributor
There was a problem hiding this comment.
Typo :)
Suggested change
| export const ECS_PATTERNS_TARGET_GROUP_PORT_FROM_COTAINER_PORT = '@aws-cdk/aws-ecs-patterns:containerPortToTargetGroupPort'; | |
| export const ECS_PATTERNS_TARGET_GROUP_PORT_FROM_CONTAINER_PORT = '@aws-cdk/aws-ecs-patterns:containerPortToTargetGroupPort'; |
Contributor
Author
There was a problem hiding this comment.
Crap. Fixed.
…ontainer port for target group port PR #18157 results in a new TargetGroup being created from NetworkLoadBalancedEc2Service, NetworkLoadBalancedFargateService, NetworkMultipleTargetGroupsEc2Service, and NetworkMultipleTargerGroupsFargateService even when no change is made because we are now passing through the containerPort props to TargetGroups's Port. For existing servies, this is a breaking change so a feature flag is needed. This PR adds that feature flag. Closes #19411.
2c2001b to
daa3216
Compare
Collaborator
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Contributor
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
4 tasks
mergify bot
pushed a commit
that referenced
this pull request
May 20, 2022
… passing container port for target group port (#20284)" (#20430) This reverts #20284 since its tests fail to pass in CDK v2, blocking the next CDK release. The root cause of failure looks as though it may be the same as #20427 - I've included the test logs below: <details> ``` @aws-cdk/aws-ecs-patterns: FAIL test/fargate/load-balanced-fargate-service-v2.test.js (11.703 s) @aws-cdk/aws-ecs-patterns: â—� When Network Load Balancer › Fargate networkloadbalanced construct uses custom Port for target group when feature flag is enabled @aws-cdk/aws-ecs-patterns: Template has 1 resources with type AWS::ElasticLoadBalancingV2::TargetGroup, but none match as expected. @aws-cdk/aws-ecs-patterns: The closest result is: @aws-cdk/aws-ecs-patterns: { @aws-cdk/aws-ecs-patterns: "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", @aws-cdk/aws-ecs-patterns: "Properties": { @aws-cdk/aws-ecs-patterns: "Port": 80, @aws-cdk/aws-ecs-patterns: "Protocol": "TCP", @aws-cdk/aws-ecs-patterns: "TargetType": "ip", @aws-cdk/aws-ecs-patterns: "VpcId": { @aws-cdk/aws-ecs-patterns: "Ref": "VPCB9E5F0B4" @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: with the following mismatches: @aws-cdk/aws-ecs-patterns: Expected 81 but received 80 at /Properties/Port (using objectLike matcher) @aws-cdk/aws-ecs-patterns: 83 | const matchError = hasResourceProperties(this.template, type, props); @aws-cdk/aws-ecs-patterns: 84 | if (matchError) { @aws-cdk/aws-ecs-patterns: > 85 | throw new Error(matchError); @aws-cdk/aws-ecs-patterns: | ^ @aws-cdk/aws-ecs-patterns: 86 | } @aws-cdk/aws-ecs-patterns: 87 | } @aws-cdk/aws-ecs-patterns: 88 | @aws-cdk/aws-ecs-patterns: at Template.hasResourceProperties (../assertions/lib/template.ts:85:13) @aws-cdk/aws-ecs-patterns: at fn (test/fargate/load-balanced-fargate-service-v2.test.ts:709:31) @aws-cdk/aws-ecs-patterns: at Object.<anonymous> (../../../tools/@aws-cdk/cdk-build-tools/lib/feature-flag.ts:34:35) @aws-cdk/aws-ecs-patterns: â—� When Network Load Balancer › test Fargate multinetworkloadbalanced construct uses custom Port for target group when feature flag is enabled @aws-cdk/aws-ecs-patterns: Template has 2 resources with type AWS::ElasticLoadBalancingV2::TargetGroup, but none match as expected. @aws-cdk/aws-ecs-patterns: The closest result is: @aws-cdk/aws-ecs-patterns: { @aws-cdk/aws-ecs-patterns: "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", @aws-cdk/aws-ecs-patterns: "Properties": { @aws-cdk/aws-ecs-patterns: "Port": 80, @aws-cdk/aws-ecs-patterns: "Protocol": "TCP", @aws-cdk/aws-ecs-patterns: "TargetType": "ip", @aws-cdk/aws-ecs-patterns: "VpcId": { @aws-cdk/aws-ecs-patterns: "Ref": "VPCB9E5F0B4" @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: with the following mismatches: @aws-cdk/aws-ecs-patterns: Expected 81 but received 80 at /Properties/Port (using objectLike matcher) @aws-cdk/aws-ecs-patterns: 83 | const matchError = hasResourceProperties(this.template, type, props); @aws-cdk/aws-ecs-patterns: 84 | if (matchError) { @aws-cdk/aws-ecs-patterns: > 85 | throw new Error(matchError); @aws-cdk/aws-ecs-patterns: | ^ @aws-cdk/aws-ecs-patterns: 86 | } @aws-cdk/aws-ecs-patterns: 87 | } @aws-cdk/aws-ecs-patterns: 88 | @aws-cdk/aws-ecs-patterns: at Template.hasResourceProperties (../assertions/lib/template.ts:85:13) @aws-cdk/aws-ecs-patterns: at fn (test/fargate/load-balanced-fargate-service-v2.test.ts:823:31) @aws-cdk/aws-ecs-patterns: at Object.<anonymous> (../../../tools/@aws-cdk/cdk-build-tools/lib/feature-flag.ts:34:35) ``` </details> ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/master/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Chriscbr
added a commit
that referenced
this pull request
May 20, 2022
… passing container port for target group port (#20284)" (#20430) This reverts #20284 since its tests fail to pass in CDK v2, blocking the next CDK release. The root cause of failure looks as though it may be the same as #20427 - I've included the test logs below: <details> ``` @aws-cdk/aws-ecs-patterns: FAIL test/fargate/load-balanced-fargate-service-v2.test.js (11.703 s) @aws-cdk/aws-ecs-patterns: â—� When Network Load Balancer › Fargate networkloadbalanced construct uses custom Port for target group when feature flag is enabled @aws-cdk/aws-ecs-patterns: Template has 1 resources with type AWS::ElasticLoadBalancingV2::TargetGroup, but none match as expected. @aws-cdk/aws-ecs-patterns: The closest result is: @aws-cdk/aws-ecs-patterns: { @aws-cdk/aws-ecs-patterns: "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", @aws-cdk/aws-ecs-patterns: "Properties": { @aws-cdk/aws-ecs-patterns: "Port": 80, @aws-cdk/aws-ecs-patterns: "Protocol": "TCP", @aws-cdk/aws-ecs-patterns: "TargetType": "ip", @aws-cdk/aws-ecs-patterns: "VpcId": { @aws-cdk/aws-ecs-patterns: "Ref": "VPCB9E5F0B4" @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: with the following mismatches: @aws-cdk/aws-ecs-patterns: Expected 81 but received 80 at /Properties/Port (using objectLike matcher) @aws-cdk/aws-ecs-patterns: 83 | const matchError = hasResourceProperties(this.template, type, props); @aws-cdk/aws-ecs-patterns: 84 | if (matchError) { @aws-cdk/aws-ecs-patterns: > 85 | throw new Error(matchError); @aws-cdk/aws-ecs-patterns: | ^ @aws-cdk/aws-ecs-patterns: 86 | } @aws-cdk/aws-ecs-patterns: 87 | } @aws-cdk/aws-ecs-patterns: 88 | @aws-cdk/aws-ecs-patterns: at Template.hasResourceProperties (../assertions/lib/template.ts:85:13) @aws-cdk/aws-ecs-patterns: at fn (test/fargate/load-balanced-fargate-service-v2.test.ts:709:31) @aws-cdk/aws-ecs-patterns: at Object.<anonymous> (../../../tools/@aws-cdk/cdk-build-tools/lib/feature-flag.ts:34:35) @aws-cdk/aws-ecs-patterns: â—� When Network Load Balancer › test Fargate multinetworkloadbalanced construct uses custom Port for target group when feature flag is enabled @aws-cdk/aws-ecs-patterns: Template has 2 resources with type AWS::ElasticLoadBalancingV2::TargetGroup, but none match as expected. @aws-cdk/aws-ecs-patterns: The closest result is: @aws-cdk/aws-ecs-patterns: { @aws-cdk/aws-ecs-patterns: "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", @aws-cdk/aws-ecs-patterns: "Properties": { @aws-cdk/aws-ecs-patterns: "Port": 80, @aws-cdk/aws-ecs-patterns: "Protocol": "TCP", @aws-cdk/aws-ecs-patterns: "TargetType": "ip", @aws-cdk/aws-ecs-patterns: "VpcId": { @aws-cdk/aws-ecs-patterns: "Ref": "VPCB9E5F0B4" @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: with the following mismatches: @aws-cdk/aws-ecs-patterns: Expected 81 but received 80 at /Properties/Port (using objectLike matcher) @aws-cdk/aws-ecs-patterns: 83 | const matchError = hasResourceProperties(this.template, type, props); @aws-cdk/aws-ecs-patterns: 84 | if (matchError) { @aws-cdk/aws-ecs-patterns: > 85 | throw new Error(matchError); @aws-cdk/aws-ecs-patterns: | ^ @aws-cdk/aws-ecs-patterns: 86 | } @aws-cdk/aws-ecs-patterns: 87 | } @aws-cdk/aws-ecs-patterns: 88 | @aws-cdk/aws-ecs-patterns: at Template.hasResourceProperties (../assertions/lib/template.ts:85:13) @aws-cdk/aws-ecs-patterns: at fn (test/fargate/load-balanced-fargate-service-v2.test.ts:823:31) @aws-cdk/aws-ecs-patterns: at Object.<anonymous> (../../../tools/@aws-cdk/cdk-build-tools/lib/feature-flag.ts:34:35) ``` </details> ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/master/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
wphilipw
pushed a commit
to wphilipw/aws-cdk
that referenced
this pull request
May 23, 2022
…ontainer port for target group port (aws#20284) PR aws#18157 results in a new TargetGroup being created from NetworkLoadBalancedEc2Service, NetworkLoadBalancedFargateService, NetworkMultipleTargetGroupsEc2Service, and NetworkMultipleTargerGroupsFargateService even when no change is made because we are now passing through the containerPort props to TargetGroups's Port. For existing services, this is a breaking change so a feature flag is needed. This PR adds that feature flag. Closes aws#19411. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
wphilipw
pushed a commit
to wphilipw/aws-cdk
that referenced
this pull request
May 23, 2022
… passing container port for target group port (aws#20284)" (aws#20430) This reverts aws#20284 since its tests fail to pass in CDK v2, blocking the next CDK release. The root cause of failure looks as though it may be the same as aws#20427 - I've included the test logs below: <details> ``` @aws-cdk/aws-ecs-patterns: FAIL test/fargate/load-balanced-fargate-service-v2.test.js (11.703 s) @aws-cdk/aws-ecs-patterns: â—� When Network Load Balancer › Fargate networkloadbalanced construct uses custom Port for target group when feature flag is enabled @aws-cdk/aws-ecs-patterns: Template has 1 resources with type AWS::ElasticLoadBalancingV2::TargetGroup, but none match as expected. @aws-cdk/aws-ecs-patterns: The closest result is: @aws-cdk/aws-ecs-patterns: { @aws-cdk/aws-ecs-patterns: "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", @aws-cdk/aws-ecs-patterns: "Properties": { @aws-cdk/aws-ecs-patterns: "Port": 80, @aws-cdk/aws-ecs-patterns: "Protocol": "TCP", @aws-cdk/aws-ecs-patterns: "TargetType": "ip", @aws-cdk/aws-ecs-patterns: "VpcId": { @aws-cdk/aws-ecs-patterns: "Ref": "VPCB9E5F0B4" @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: with the following mismatches: @aws-cdk/aws-ecs-patterns: Expected 81 but received 80 at /Properties/Port (using objectLike matcher) @aws-cdk/aws-ecs-patterns: 83 | const matchError = hasResourceProperties(this.template, type, props); @aws-cdk/aws-ecs-patterns: 84 | if (matchError) { @aws-cdk/aws-ecs-patterns: > 85 | throw new Error(matchError); @aws-cdk/aws-ecs-patterns: | ^ @aws-cdk/aws-ecs-patterns: 86 | } @aws-cdk/aws-ecs-patterns: 87 | } @aws-cdk/aws-ecs-patterns: 88 | @aws-cdk/aws-ecs-patterns: at Template.hasResourceProperties (../assertions/lib/template.ts:85:13) @aws-cdk/aws-ecs-patterns: at fn (test/fargate/load-balanced-fargate-service-v2.test.ts:709:31) @aws-cdk/aws-ecs-patterns: at Object.<anonymous> (../../../tools/@aws-cdk/cdk-build-tools/lib/feature-flag.ts:34:35) @aws-cdk/aws-ecs-patterns: â—� When Network Load Balancer › test Fargate multinetworkloadbalanced construct uses custom Port for target group when feature flag is enabled @aws-cdk/aws-ecs-patterns: Template has 2 resources with type AWS::ElasticLoadBalancingV2::TargetGroup, but none match as expected. @aws-cdk/aws-ecs-patterns: The closest result is: @aws-cdk/aws-ecs-patterns: { @aws-cdk/aws-ecs-patterns: "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", @aws-cdk/aws-ecs-patterns: "Properties": { @aws-cdk/aws-ecs-patterns: "Port": 80, @aws-cdk/aws-ecs-patterns: "Protocol": "TCP", @aws-cdk/aws-ecs-patterns: "TargetType": "ip", @aws-cdk/aws-ecs-patterns: "VpcId": { @aws-cdk/aws-ecs-patterns: "Ref": "VPCB9E5F0B4" @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: } @aws-cdk/aws-ecs-patterns: with the following mismatches: @aws-cdk/aws-ecs-patterns: Expected 81 but received 80 at /Properties/Port (using objectLike matcher) @aws-cdk/aws-ecs-patterns: 83 | const matchError = hasResourceProperties(this.template, type, props); @aws-cdk/aws-ecs-patterns: 84 | if (matchError) { @aws-cdk/aws-ecs-patterns: > 85 | throw new Error(matchError); @aws-cdk/aws-ecs-patterns: | ^ @aws-cdk/aws-ecs-patterns: 86 | } @aws-cdk/aws-ecs-patterns: 87 | } @aws-cdk/aws-ecs-patterns: 88 | @aws-cdk/aws-ecs-patterns: at Template.hasResourceProperties (../assertions/lib/template.ts:85:13) @aws-cdk/aws-ecs-patterns: at fn (test/fargate/load-balanced-fargate-service-v2.test.ts:823:31) @aws-cdk/aws-ecs-patterns: at Object.<anonymous> (../../../tools/@aws-cdk/cdk-build-tools/lib/feature-flag.ts:34:35) ``` </details> ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/master/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
TheRealAmazonKendra
added a commit
that referenced
this pull request
Jul 6, 2022
…ontainer port for target group port This re-implements #20284, which was reverted in #20430 due to the feature flag tests. PR #18157 results in a new TargetGroup being created from NetworkLoadBalancedEc2Service, NetworkLoadBalancedFargateService, NetworkMultipleTargetGroupsEc2Service, and NetworkMultipleTargerGroupsFargateService even when no change is made because we are now passing through the containerPort props to TargetGroups's Port. For existing services, this is a breaking change so a feature flag is needed. This PR adds that feature flag. Closes #19411.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR #18157 results in a new TargetGroup being created from NetworkLoadBalancedEc2Service, NetworkLoadBalancedFargateService, NetworkMultipleTargetGroupsEc2Service,
and NetworkMultipleTargerGroupsFargateService even when no change is made because we are now passing through the containerPort props to TargetGroups's Port.
For existing services, this is a breaking change so a feature flag is needed. This PR adds that feature flag.
Closes #19411.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license