Skip to content

Conversation

@vikas-bh
Copy link
Contributor

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

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.

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 <[email protected]>
// 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 <[email protected]>
@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