-
Notifications
You must be signed in to change notification settings - Fork 603
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 support for IP Family Policy and IP Families #4076
Conversation
Add IP Family Policy and IP Families to CRD for Services
upstream changes
upstream changes
update to enum for IP Families
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.
A couple questions about the types in CRD structs.
// --- | ||
// +optional | ||
// +kubebuilder:validation:Enum=SingleStack;PreferDualStack;RequireDualStack | ||
IPFamilyPolicy string `json:"ipFamilyPolicy,omitempty"` |
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 we can avoid the type conversions in the controller if we use the upstream type here. Similar regarding pointer. Does this generate the same YAML?
IPFamilyPolicy string `json:"ipFamilyPolicy,omitempty"` | |
IPFamilyPolicy *corev1.IPFamilyPolicy `json:"ipFamilyPolicy,omitempty"` |
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.
yes it does - thanks - refactoring
// +optional | ||
IPFamilies []IPFamily `json:"ipFamilies,omitempty"` |
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.
❓ We should be able to use the upstream type and add the enum validation from here. Does this generate the same YAML?
// +optional | |
IPFamilies []IPFamily `json:"ipFamilies,omitempty"` | |
// +optional | |
// +kubebuilder:validation:items:Enum={IPv4,IPv6} | |
IPFamilies []corev1.IPFamily `json:"ipFamilies,omitempty"` |
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.
yes it does - thanks - refactoring
service.Spec.IPFamilyPolicy = &policy | ||
} | ||
if len(spec.IPFamilies) > 0 { | ||
service.Spec.IPFamilies = []corev1.IPFamily{} |
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.
📝 If the Go types in the CRD structs can change, these assignments might reduce to service.Spec... = spec...
.
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.
yes - this one simplified also - thanks for the suggestion
The code to pass through these values looks good 👍 Have you looked for tests where we are checking that ServiceSpec values are being passed into the service? |
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 don't think tests for this change would be doing much. It would basically be making sure that anything that shows up in the CR ends up on the service spec.
Since we already don't have tests for TrafficPolicy
, I feel ok merging this without updating the tests
if spec.IPFamilyPolicy != nil { | ||
service.Spec.IPFamilyPolicy = spec.IPFamilyPolicy | ||
} | ||
if len(spec.IPFamilies) > 0 { | ||
service.Spec.IPFamilies = spec.IPFamilies | ||
} |
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 check len or nil.
Checklist:
Type of Changes:
What is the current behavior (link to any open issues here)?
Currently the CRD does not manage the
ipFamilyPolicy
oripFamilies
fields on the Services managed by CPK. This makes it more difficult for users in IPv6 and DualStack environments.What is the new behavior (if this is a feature change)?
Other Information: