-
Notifications
You must be signed in to change notification settings - Fork 303
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
Add flag for IPV6 only NEG's #2763
base: master
Are you sure you want to change the base?
Conversation
Welcome @zasweq! |
Hi @zasweq. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/assign @swetharepakula |
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 @zasweq
pkg/flags/flags.go
Outdated
@@ -334,6 +335,7 @@ L7 load balancing. CSV values accepted. Example: -node-port-ranges=80,8080,400-5 | |||
flag.BoolVar(&F.EnableL4ILBMixedProtocol, "enable-l4ilb-mixed-protocol", false, "Enable support for mixed protocol L4 internal load balancers.") | |||
flag.BoolVar(&F.EnableL4NetLBMixedProtocol, "enable-l4netlb-mixed-protocol", false, "Enable support for mixed protocol L4 external load balancers.") | |||
flag.StringVar(&F.ClusterSliceAPIGroup, "cluster-slice-api-group", "", "The API group for the ClusterSlice CRD.") | |||
flag.BoolVar(&F.EnableIPV6NEG, "enable-ipv6-neg", false, "Enable support for IPV6 NEG's.") |
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.
nit: Can we use enable-ipv6-only-neg
for clarity? (If we do, let's propagate the same to the variable names 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.
Ah, good point. The error message returned from config verification says only and so do the tests. Switched.
/ok-to-test |
{ | ||
desc: "ipv6 only service with l7 load balancer, ipFamilyPolicy is singleStack, ipv6 neg enabled", | ||
serviceType: v1.ServiceTypeClusterIP, | ||
ipFamilies: []v1.IPFamily{v1.IPv6Protocol}, |
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'd just like to make sure the tests cover all the cases. Sorry if my comments are off, because I may not have all the context. A customer in a single stack IPv6 cluster could create a normal Service, where the Spec lacks ipFamilies
or ipFamilyPolicy
. Because the cluster is single stack IPv6 and IPv6 is the only family available, the Service will only have IPv6 addresses, and so the backends, and the NEGs would be only configured with an IPv6 address. So theoretically there is a case where these fields are not set, but a NEG in the end would only have an IPv6 address. I don't know if this matters, maybe it's not possible to add coverage just with unit tests. WDYT?
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 see what you're saying. For the scope of this specific unit test, which tests at the validation boundary, I think what to test here would be for an unset IP family to pass validation.
However, I wonder how to test this e2e. It would require however we determine the GKE Cluster's stack type and see if IPV6 + unset, and see if unset spins up a IPv6.
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.
Hmm ok I'll add a test for unset ipFamilies and ipFamily policy at the unit test layer. I'm assuming that for IPV4 only it'll simply create an IPV4 NEG, just as in the case of IPV6 only cluster it's valid and we want it to create an IPV6 only NEG.
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 @krzykwas, I wasn't aware about the "theoretically there is a case where these fields are not set, but a NEG in the end would only have an IPv6 address" case. Good to have become aware about this.
But yes, this unit test here will not be able to exercise this check and we'll either need some kind of an integration test, or write a standard e2e test.
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.
Ok sounds good. Let's leave this test to an integration or e2e test then.
/approve (Pending LGTM from Swetha) |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gauravkghildiyal, zasweq The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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 for making the changes!
One nit in how the test was written.
Otherwise can you squash the commits as well? Or please expand the second commit message with more context.
@@ -1590,9 +1590,9 @@ func TestServiceIPFamilies(t *testing.T) { | |||
for _, tc := range testCases { | |||
t.Run(tc.desc, func(t *testing.T) { | |||
if tc.enableIPV6OnlyNEG { | |||
flags.F.EnableIPV6NEG = true | |||
flags.F.EnableIPV6OnlyNEG = 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.
since this is a global variable, can you store the previous value and reset it in the defer. As the tests grow using this flag, I think that will be safer in terms of test pollution. Thanks
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.
Ah, good point. That is how we set env vars in gRPC-Go tests too. Thanks.
Rebased and squashed all commits including those that address comments into one commit only. |
This PR adds a flag for IPV6 only NEG's. If the flag is false, then the NEG Controller will still error if an IPV6 only service is configured.
The plan is to flag flip in a patch release once IPV6 NEG support is available in production (requires GCP LB support for IPV6 only NEG's).