-
Notifications
You must be signed in to change notification settings - Fork 298
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
Update workload when job changes before admission #1223
Update workload when job changes before admission #1223
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
Hi @yaroslava-serdiuk. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
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.
Generally LGTM, just a question regarding the scenario when the job is running.
f1f4693
to
c6a3d26
Compare
/lgtm |
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 also need to modify the workload_webhook, as it currently has PodSets as immutable.
Also please add a integration test for Job that starts with one that doesn't fit in the quota, (record the creationTimestmap of the Worklad at this point) and gets admitted after being updated to a smaller size (ensure that the creationTimestamp didn't change)
/lgtm cancel |
c6a3d26
to
aa11027
Compare
f2debd9
to
07bbe48
Compare
@alculquicondor |
07bbe48
to
fa7e92b
Compare
3e1243f
to
4a3546e
Compare
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
LGTM label has been added. Git tree hash: ae7a2bf2a9c60f07070d2f22969c82beea38bf60
|
/release-note-edit
|
@@ -874,6 +874,26 @@ func TestReconciler(t *testing.T) { | |||
}, | |||
wantErr: jobframework.ErrNoMatchingWorkloads, | |||
}, | |||
"non-matching non-admitted workload is updated": { |
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.
Let's add a case for when the Workload has a quota reservation. In that case we would remove the existing Workload, right?
We might want to change what to do with a Workload that is admitted when the requests change, but that's for #77
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 the case for that just above current test ("non-matching admitted workload is deleted")
Resources requests are immutable, the user can't change them |
/release-note-edit
|
allErrs = append(allErrs, apivalidation.ValidateImmutableField(newObj.Spec.PriorityClassSource, oldObj.Spec.PriorityClassSource, specPath.Child("priorityClassSource"))...) | ||
allErrs = append(allErrs, apivalidation.ValidateImmutableField(newObj.Spec.PriorityClassName, oldObj.Spec.PriorityClassName, specPath.Child("priorityClassName"))...) | ||
|
||
if workload.HasQuotaReservation(oldObj) { |
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.
What is the rationale for only checking oldObj
?
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 want to update the workload that doesn't have a quota reservation and this is oldObj.
I think if the update function is called for new object that has quota reservation and the old doesn't (not sure what the real case for that), it's should be the same as we call update first for new obj without quota reservation and then reserve the quota.
My understanding why we check the quota is that we can't guarantee the quota for new object, so we want to do updates when the quota is not reserved. If the quota is fine for new object, than we are fine.
Do I miss something?
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.
Yeah, I think that's fine.
I just remembered that it is not possible to update Spec and Status at the same time.
4a3546e
to
9df2318
Compare
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.
/approve
/lgtm
LGTM label has been added. Git tree hash: a1a77f08b74d82f96dfe792cdb45de5e582e1ff1
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alculquicondor, yaroslava-serdiuk 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 |
return nil, fmt.Errorf("can't construct workload for update: %w", err) | ||
} | ||
wl.Spec = newWl.Spec | ||
if err = r.client.Update(ctx, wl); err != nil { |
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 the key point here is we'll replace the unadmitted workload with the newest spec. right?
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.
Correct. However note, that currently we can update only the amount of pods/containers: #1264
What type of PR is this?
/kind feature
Which issue(s) this PR fixes:
Fixes #1038
Does this PR introduce a user-facing change?