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
Incrementing EndpointSlice generation when labels change #99750
Incrementing EndpointSlice generation when labels change #99750
Conversation
EndpointSlice labels can be quite meaningful. They are used to indicate the controller they are managed by and the Service they are associated with. Changing these labels can have significant affects on how the EndpointSlice is consumed so incrementing generation seems appropriate.
@@ -65,7 +65,7 @@ func (endpointSliceStrategy) PrepareForUpdate(ctx context.Context, obj, old runt | |||
newEPS.ObjectMeta = v1.ObjectMeta{} | |||
oldEPS.ObjectMeta = v1.ObjectMeta{} | |||
|
|||
if !apiequality.Semantic.DeepEqual(newEPS, oldEPS) { | |||
if !apiequality.Semantic.DeepEqual(newEPS, oldEPS) || !apiequality.Semantic.DeepEqual(ogNewMeta.Labels, ogOldMeta.Labels) { |
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 was actually suggesting going even step further and adding:
else {
ogNewMeta.Generation = og.OldMeta.Generation
}
But I would like to hear Jordan`s opinion (if that doesn't violate some conventions, backward compatibility, etc.)
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.
rest.BeforeUpdate already resets generation to the current value before calling strategy.PrepareForUpdate:
kubernetes/staging/src/k8s.io/apiserver/pkg/registry/rest/update.go
Lines 105 to 113 in c8fe1d9
objectMeta.SetGeneration(oldMeta.GetGeneration()) | |
// Ensure managedFields state is removed unless ServerSideApply is enabled | |
if !utilfeature.DefaultFeatureGate.Enabled(features.ServerSideApply) { | |
oldMeta.SetManagedFields(nil) | |
objectMeta.SetManagedFields(nil) | |
} | |
strategy.PrepareForUpdate(ctx, obj, old) |
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.
Good point - I missed that thanks.
there's precedent from deployments for considering specific fields outside spec in computing generation: kubernetes/pkg/registry/apps/deployment/strategy.go Lines 106 to 109 in c8fe1d9
this seems reasonable to me, but will defer final ack to @thockin who has more context on the endpointslice API bits /unassign |
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!
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: robscott, thockin 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 |
For posterity - LGTM too. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
EndpointSlice labels can be quite meaningful. They are used to indicate the controller they are managed by and the Service they are associated with. Changing these labels can have significant effects on how the EndpointSlice is consumed so incrementing generation seems appropriate.
Special notes for your reviewer:
This is especially relevant to #99345 where we updated the EndpointSlice controller to track EndpointSlice generations. This change to strategy was suggested by @wojtek-t in #99345 (comment).
Does this PR introduce a user-facing change?
/sig network
/triage accepted
/priority important-soon
/cc @wojtek-t @aojea
/assign @liggitt