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

Add NatFlags flag to OutboundNatPolicySetting #1013

Merged
merged 3 commits into from
Apr 30, 2021

Conversation

vikas-bh
Copy link
Contributor

This is to allow setting the ipv6 flag when creating outbound nat policy.

@@ -135,6 +135,7 @@ type OutboundNatPolicySetting struct {
VirtualIP string `json:",omitempty"`
Exceptions []string `json:",omitempty"`
Destinations []string `json:",omitempty"`
Flags NatFlags `json:",omitempty"`
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It appears that the version check for ipv6 support already exists in the form of IPv6DualStackSupported. If more checks need to be added please let me know.

@@ -135,6 +135,7 @@ type OutboundNatPolicySetting struct {
VirtualIP string `json:",omitempty"`
Exceptions []string `json:",omitempty"`
Destinations []string `json:",omitempty"`
Flags NatFlags `json:",omitempty"`
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should an enum be defined as well for each value of NatFlags? Right now its just declared as an int:
// NatFlags are flags for portmappings.
type NatFlags uint32

so I did not add one just for ipv6.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I think it's a good idea to define the enum. Something like this

@dcantah
Copy link
Contributor

dcantah commented Apr 29, 2021

@vikas-bh Thanks Vikas. Could you sign off on the commit with git commit --amend --signoff? Change LGTM though

Signed-off-by: Vikas Bhardwaj <vikasb@microsoft.com>
Signed-off-by: Vikas Bhardwaj <vikasb@microsoft.com>
@@ -36,6 +36,7 @@ var (
LoadBalancerFlagsNone LoadBalancerFlags = 0
// LoadBalancerFlagsDSR enables Direct Server Return (DSR)
LoadBalancerFlagsDSR LoadBalancerFlags = 1
LoadBalancerFlagsIPv6 LoadBalancerFlags = 2
)
Copy link
Contributor

Choose a reason for hiding this comment

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

Ideally these would be constants also, is there any reason they aren't?

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have no idea why they were not made constants in the first place over here :). I would prefer we not change this as these are being used from kubeproxy.

Copy link
Contributor

Choose a reason for hiding this comment

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

Just checking in case anyone knew 😆. Them being constants wouldn't affect anything on them pulling in a new release though, so it should be harmless. They'll be the same type (and value), just not reassignable now.

Copy link
Contributor

Choose a reason for hiding this comment

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

Just code hygiene

@dcantah
Copy link
Contributor

dcantah commented Apr 29, 2021

@vikas-bh I can probably push a change right after to fix the things that should be constants, unless you want to. Do we want a new release of the shim with these changes? Is this for k8s?

@vikas-bh
Copy link
Contributor Author

@vikas-bh I can probably push a change right after to fix the things that should be constants, unless you want to. Do we want a new release of the shim with these changes? Is this for k8s?

This is for ipv6 support being added to the Windows CNI (it is under development). I say we hold on for a bit before creating a new release in case there are more things we find which need to be fixed in hcsshim.

Signed-off-by: Vikas Bhardwaj <vikasb@microsoft.com>
@dcantah
Copy link
Contributor

dcantah commented Apr 29, 2021

@vikas-bh Sounds good!

@sbangari
Copy link

/lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants