-
Notifications
You must be signed in to change notification settings - Fork 479
Introduce workload.PatchStatus function to commonize workload status updates #8063
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
Introduce workload.PatchStatus function to commonize workload status updates #8063
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| if updated, err := update(wl); err != nil || !updated { | ||
| return updated, err | ||
| } | ||
| if !features.Enabled(features.WorkloadRequestUseMergePatch) { |
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.
In PatchAdmissionStatus, we should first apply the desired changes and then execute PrepareWorkloadPatch. But in PatchStatus, we should start with BaseSSAWorkload patch and apply the changes afterward.
7736341 to
06f8280
Compare
|
/retitle Introduce workload.PatchStatus function to commonize workload status updates |
8e62a7d to
fa678b5
Compare
e231766 to
3473192
Compare
8dbde58 to
75978bf
Compare
|
LGTM label has been added. Git tree hash: 3870fd8964c77a0fced0c3e42252b3783c45979c
|
5c10848 to
e354e53
Compare
|
Looks like this is flaky issue. Created fix #8073. |
|
cc: @mimowo |
e9e5752 to
e354e53
Compare
|
https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/kubernetes-sigs_kueue/8063/pull-kueue-test-e2e-customconfigs-main/1996583380052873216 |
I think this is a flake #5106. But after introducing 4573156, we’re seeing this flake more often. |
|
/retest Due to #8073 merged. |
e354e53 to
dbaa8e1
Compare
| return updated, err | ||
| } | ||
| if !features.Enabled(features.WorkloadRequestUseMergePatch) { | ||
| wlPatch := PrepareWorkloadPatch(wl, opts.StrictApply, clk) |
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 need to rename this function, or even remove and just use
wlPatch := BaseSSAWorkload(wl, opts.StrictApply)
PrepareAdmissionPatch(w, wlCopy, clk)
return wlCopywhere PrepareAdmissionPatch encapsulates the functions:
admissionStatusPatch
admissionChecksStatusPatch
It is rather a follow up
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 have other places that use this function. After fully migrating to this approach, I think we can remove it entirely.
| wlPatch := BaseSSAWorkload(wl, opts.StrictApply) | ||
| wlPatch.DeepCopyInto(wl) | ||
| } | ||
| return update(wl) |
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.
Why is the update here at the bottom, and for PatchAdmissionStatus it is at the top?
I think it is actually slightly better to place it at the top, then it can make adjustments based on the original workload.
Also, I'm wondering if we could then commonize calling update and place it inside patchStatus, wdyt?
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.
It will not work. In some places we use other fields to construct the status (for example .spec.localQueue). If we move it before the update, we will get a lot of errors because the fields will be empty.
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.
Right but my point is to move calling the update before BaseSSAWorkload in both cases, would this not work either?
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.
Unfortunately no.
kueue/pkg/workload/workload.go
Lines 735 to 757 in 98c941f
| func BaseSSAWorkload(w *kueue.Workload, strict bool) *kueue.Workload { | |
| wlCopy := &kueue.Workload{ | |
| ObjectMeta: metav1.ObjectMeta{ | |
| UID: w.UID, | |
| Name: w.Name, | |
| Namespace: w.Namespace, | |
| Generation: w.Generation, // Produce a conflict if there was a change in the spec. | |
| Annotations: maps.Clone(w.Annotations), | |
| Labels: maps.Clone(w.Labels), | |
| }, | |
| TypeMeta: w.TypeMeta, | |
| } | |
| if wlCopy.APIVersion == "" { | |
| wlCopy.APIVersion = kueue.GroupVersion.String() | |
| } | |
| if wlCopy.Kind == "" { | |
| wlCopy.Kind = "Workload" | |
| } | |
| if strict { | |
| wlCopy.ResourceVersion = w.ResourceVersion | |
| } | |
| return wlCopy | |
| } |
Base BaseSSAWorkload() creates almost empty patch.
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.
So after patch creation we will loose all changes.
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.
Do you mean that calling wlPatch.DeepCopyInto(wl) would zero all the workload fields in wl other than those in the wlPatch?
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, exactly – we will replace all fields with zero values after running wlPatch.DeepCopyInto(wl).
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.
Gotcha. I think to make it more generic we may actually make the update function to accept two workloads (origWorkload, patchWorkload). Then, if all fields are needed, then it would use origWorkload, but it would record changes to patchWorkload. However, this may not be very easy because many functions we have don't make this distinction.
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'm ok for now, but this is something we may need to still rethink , but I still don't know the ideal state for now, so let's keep it evolving and see where we are.
mimowo
left a comment
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.
LGTM overall, thank you for commonizing. It will make it easier to maintain over time. I have one comment to potentially commonize the code even more https://github.com/kubernetes-sigs/kueue/pull/8063/files#r2593474604
It could also be a follow up.
mimowo
left a comment
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.
/lgtm
/approve
Thank you 👍
|
LGTM label has been added. Git tree hash: b8778772b523d5eb46ffc7b84fbf00b48da3a5d5
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mbobrovskyi, mimowo 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 |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Use PatchStatus().
Which issue(s) this PR fixes:
Part of #7035
Special notes for your reviewer:
As we discussed here #8031 (comment) we should comminize patch logic.
Does this PR introduce a user-facing change?