-
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
fix(elbv2): unable to deploy template with IPv4 load balancer when denyAllIgwTraffic set #29956
Conversation
5e4292f
to
89cc140
Compare
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. Dismissing previous PRLinter review.
14467eb
to
291c665
Compare
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.
I think your change is affecting unrelated configurations, I would double check your condition and what you're expecting it do accomplish
I would also like to see additional unit tests, a combination of the following possibilities. I'm not sure what's the expected behavior for some of them, and coverage is always good:
denyAllIgwTraffic: undefined
/denyAllIgwTraffic: false
/denyAllIgwTraffic: true
ipAddressType: undefined
/ipAddressType: IpAddressType.IPV4
/ipAddressType: IpAddressType.DUALSTACK
Would you also be able to add additional integration tests to make sure that denyAllIgwTraffic: false
and ipAddressType: IpAddressType.DUALSTACK
is being deployed correctly?
@@ -488,6 +484,21 @@ describe('tests', () => { | |||
}).toThrow('Load balancer name: "my load balancer" must contain only alphanumeric characters or hyphens.'); | |||
}); | |||
|
|||
test('loadBalancerName unallowed: denyAllIgwTraffic set to false for Ipv4 adressing', () => { |
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.
test('loadBalancerName unallowed: denyAllIgwTraffic set to false for Ipv4 adressing', () => { | |
test('throw error for denyAllIgwTraffic set to false for Ipv4 adressing', () => { |
@@ -250,7 +251,9 @@ export abstract class BaseLoadBalancer extends Resource { | |||
this.setAttribute('load_balancing.cross_zone.enabled', baseProps.crossZoneEnabled === true ? 'true' : 'false'); | |||
} | |||
|
|||
if (baseProps.denyAllIgwTraffic !== undefined) { | |||
if (additionalProps.ipAddressType === IpAddressType.IPV4 && baseProps.denyAllIgwTraffic === false) { |
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.
ipAddressType
is meant to be IpAddressType.IPV4
by default, and denyAllIgwTraffic
is supposed to be false
, I assume this condition is incorrect?
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.
Appreciate the feedback! Apologies for the spiel
Yes, ipAddressType
is meant to be IpAddressType.IPV4
. As for denyAllIgwTraffic
the docs mention "optional, default: false for internet-facing load balancers and true for internal load balancers". Looking at code though, denyAllIgwTraffic
is never actually given a default value which is why we have this check for undefined
here.
The denyAllIgwTraffic
was created from this issue: #29520. Basically
denyAllIgwTraffic
is supposed to set ipv6.deny_all_igw_traffic
. However, having ipv6.deny_all_igw_traffic
set (to either true or false) for any Ipv4 load balancer will cause a failed deployment. I'm starting to think the condition should actually be this:
if (additionalProps.ipAddressType === IpAddressType.IPV4 && baseProps.denyAllIgwTraffic === false) { | |
if (additionalProps.ipAddressType === IpAddressType.IPV4 && baseProps.denyAllIgwTraffic !== undefined) { |
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.
Looking at code though,
denyAllIgwTraffic
is never actually given a default value which is why we have this check for undefined here.
The CDK doesn't always set the default values, in fact most of the time CloudFormation does. This is the case here, although it's more complicated than just defaulted to false
, see docs. The @default
value needs to be updated to reflect this
{ | ||
"Key": "ipv6.deny_all_igw_traffic", | ||
"Value": "true" | ||
}, |
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.
That's a scary change, I'm going to assume it's an unintended side effect. Given the integration was being deployed before your change, I assume the integ stack was being deployed successfully
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.
Hehe, well that's the thing, I could not deploy the integration test before my change. The deployment failed with
Resource handler returned message: "Load balancer attribute key 'ipv6.deny_all_igw_traffic' is not supported on load balancers with IP address type 'ipv4'.
That's why I renamed the test to, in effect, remove the old test and replace with a template you can deploy (the name I use also aligns with the existing alb test). This particular integration test was added very recently. I can only think that who ever created it only synthesized the test and didn't try deploying.
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.
@badmintoncryer Could we get some clarification on this? See #29521
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.
Surely I haven't created a snapshot without deploying it...
I'll try it later. Please wait for a while.
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.
@nmussy @Michae1CC
I tried to deploy integ.nlb-attributes.ts
but it cannot. I'm really sorry and I don't know how I could create snapshot files...
I have conducted deployment verification for internal ALBs and NLBs across several patterns.
The results are the same for both ALB and NLB.
ipAddressType |
denyAllIgwTraffic |
deployment result | error message |
---|---|---|---|
IPV4 | true | failed | Load balancer attribute key 'ipv6.deny_all_igw_traffic' is not supported on load balancers with IP address type 'ipv4'. |
IPV4 | false | failed | Load balancer attribute key 'ipv6.deny_all_igw_traffic' is not supported on load balancers with IP address type 'ipv4'. |
DUAL_STACK | true | success | |
DUAL_STACK | false | failed | Load balancer attribute key 'ipv6.deny_all_igw_traffic' cannot be modified for load balancers of type 'network'. |
Based on these results, I propose the following amendments:
- If
denyAllIgwTraffic
is defined, return an error ifipAddressType
is notDUAL_STACK
. - Revise the existing
integ.nlb-attributes.ts
to make it deployable:
- Remove the
denyAllIgwTraffic
setting. - Instead, set
denyAllIgwTraffic
ininteg.nlb.dualstack.internal.ts
.
For item 2, it might be better to handle it as a separate issue.
If so, I will take responsibility for addressing it.
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.
@Michae1CC My only suggestion is that the PR title should describe the content of the bug being resolved, rather than just mentioning the resolution of integration test errors.
Titles for feat and fix PRs end up in the change log. Think about what makes most sense for users reading the changelog while writing them.
- feat: describe the feature (not the action of creating the commit or PR, for example, avoid words like "added" or "changed")
- fix: describe the bug (not the solution)
Since I am unable to conduct community reviews, it would be best for the rest to be checked by @nmussy .
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.
Gotcha, maybe something like integ test for NLB attributes failing to deploy due to setting denyAllIgwTraffic
?
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.
I apologize, I finally realized that this was actually a PR intended to resolve an integration test error. My English skills are limited and I made a significant misunderstanding. My suggestion to split the PR also made no sense. I'm sorry.
Without specifically mentioning the integration test, how about using the title:
'fix(elbv2): unable to deploy an IPv4 load balancer with denyAllIgwTraffic
enabled'?
or considering it as the addition of a verification feature,
'feat(elbv2): verification of denyAllIgwTraffic
for IPv4 Load Balancers'
However, I would appreciate it if you could consider nmussy opinion on this matter 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.
No need to apologize! And I agree, this PR's goal is not to fix an integration test, it's to prevent this pattern from being synthesized in the first place
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.
Thanks both, updated the title
@Michae1CC I also left you a general comment in the review, in case you didn't see it: #29956 (review) |
Yes, thanks again! I'll add more tests once we've aligned on the expected behaviour. |
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. Dismissing previous PRLinter review.
Hey both, updated the integration tests and PR description. Let me know what you think. |
This PR isn't changing much. The biggest change (in terms of functionality) will be that the deploy error you got will now occur during synthesis with a more descriptive message. |
@moelasmar , let me know if anything else needs to change - thanks. |
thanks @Michae1CC for raising this PR and fix this issue. It looks good to me, I will create a github issue for this PR, and link it to this PR (just for tracking purposes). I need also to verify the integration test cases on my side before approving it. |
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). |
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 CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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). |
…nyAllIgwTraffic set (aws#29956) ### Issue # (if applicable) Closes aws#30247 . ### Reason for this change Integ test for NLB attributes ([integ.nlb-attributes.ts](https://github.com/aws/aws-cdk/blob/4f1c94b27ef7f4ceccea0ff39625c0e8add31c9f/packages/%40aws-cdk-testing/framework-integ/test/aws-elasticloadbalancingv2/test/integ.nlb-attributes.ts)) fails to deploy due to an error. The error occurs when `denyAllIgwTraffic` is explicitly set for load balancers with Ipv4 addressing, the `ipv6.deny_all_igw_traffic` attribute is set. ### Description of changes - Remove the denyAllIgwTraffic setting from integ.nlb-attribute.ts - Instead, set denyAllIgwTraffic in integ.nlb.dualstack.internal.ts. - Raise an error during synthesis if `denyAllIgwTraffic` is set on a load balancer that does not use dual stack addressing. ### Description of how you validated changes - Added new unit tests for different combinations of `denyAllIgwTraffic` and `ipAddressType` - Updated existing integration test ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one. |
Issue # (if applicable)
Closes #30247 .
Reason for this change
Integ test for NLB attributes (integ.nlb-attributes.ts) fails to deploy due to an error. The error occurs when
denyAllIgwTraffic
is explicitly set for load balancers with Ipv4 addressing, theipv6.deny_all_igw_traffic
attribute is set.Description of changes
denyAllIgwTraffic
is set on a load balancer that does not use dual stack addressing.Description of how you validated changes
denyAllIgwTraffic
andipAddressType
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license