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 support for IP Family Policy and IP Families #4076

Merged
merged 14 commits into from
Jan 29, 2025

Conversation

philrhurst
Copy link
Contributor

@philrhurst philrhurst commented Jan 22, 2025

Checklist:

  • Have you added an explanation of what your changes do and why you'd like them to be included?
  • Have you updated or added documentation for the change, as applicable?
  • Have you tested your changes on all related environments with successful results, as applicable?
    • Have you added automated tests?

Type of Changes:

  • New feature
  • Bug fix
  • Documentation
  • Testing enhancement
  • Other

What is the current behavior (link to any open issues here)?

Currently the CRD does not manage the ipFamilyPolicy or ipFamilies 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)?

  • Breaking change (fix or feature that would cause existing functionality to change)

Other Information:

@andrewlecuyer andrewlecuyer requested a review from jmckulk January 28, 2025 17:43
Copy link
Member

@cbandy cbandy left a 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"`
Copy link
Member

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?

Suggested change
IPFamilyPolicy string `json:"ipFamilyPolicy,omitempty"`
IPFamilyPolicy *corev1.IPFamilyPolicy `json:"ipFamilyPolicy,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.

yes it does - thanks - refactoring

Comment on lines 57 to 58
// +optional
IPFamilies []IPFamily `json:"ipFamilies,omitempty"`
Copy link
Member

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?

Suggested change
// +optional
IPFamilies []IPFamily `json:"ipFamilies,omitempty"`
// +optional
// +kubebuilder:validation:items:Enum={IPv4,IPv6}
IPFamilies []corev1.IPFamily `json:"ipFamilies,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.

yes it does - thanks - refactoring

Comment on lines 313 to 316
service.Spec.IPFamilyPolicy = &policy
}
if len(spec.IPFamilies) > 0 {
service.Spec.IPFamilies = []corev1.IPFamily{}
Copy link
Member

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....

Copy link
Contributor Author

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

@philrhurst philrhurst requested a review from cbandy January 28, 2025 19:37
@jmckulk
Copy link
Collaborator

jmckulk commented Jan 28, 2025

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?

Copy link
Collaborator

@jmckulk jmckulk left a 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

Comment on lines +272 to +277
if spec.IPFamilyPolicy != nil {
service.Spec.IPFamilyPolicy = spec.IPFamilyPolicy
}
if len(spec.IPFamilies) > 0 {
service.Spec.IPFamilies = spec.IPFamilies
}
Copy link
Member

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.

@philrhurst philrhurst merged commit 740400d into CrunchyData:main Jan 29, 2025
19 checks passed
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.

3 participants