-
Notifications
You must be signed in to change notification settings - Fork 500
add priority class to wl none -> some #8480
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
base: main
Are you sure you want to change the base?
add priority class to wl none -> some #8480
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: andrewseif The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @andrewseif. 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. DetailsInstructions 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-sigs/prow repository. |
|
/ok-to-test |
|
@andrewseif could you please rebase PR? |
| } | ||
|
|
||
| func ValidateUpdateForWorkloadPriorityClassName(isSuspended bool, oldObj, newObj client.Object) field.ErrorList { | ||
| // Cannot ADD a priority class to a NON-suspended (running) workload && wpc is 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.
If we want to support adding a priority class, I think we should allow it.
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.
as far as I understand the issue mentioned suspended workloads, this piece of code is only affecting running on.
If we change this if condition, it means we allow priority change to running workloads (if I get the code 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.
Ah, I see, you right, we want to fix only suspended workloads.
fa60457 to
f719eea
Compare
| oldName := workload.PriorityClassName(old) | ||
| newName := workload.PriorityClassName(new) | ||
|
|
||
| return newName != "" && oldName != newName |
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.
You are checking only name here. What about priority?
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 this code block we check that the new wl has a wpc
if !workload.IsWorkloadPriorityClass(new) { return false }
and that's what we care about since we want to allow none wpc -> some wpc
| return true | ||
| } | ||
| // Check if priority value changed (for WorkloadPriorityClass value updates). | ||
| return priority.Priority(old) != priority.Priority(new) |
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 about this?
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 this is more restrictive? its checking (as far as I understand) the priority itself (low or high...etc), but I don't think it would work in a none ->some scenario?
in my case we are checking if old not equal new, and if new isn't empty. so no (some -> none scenario).
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.
Please don't remove this logic.
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 reverted the changes to this logic, but removed the culprit which is checking old prio, please check and tell me if that's ok now 😄
bd900af to
ca335de
Compare
Co-authored-by: Mykhailo Bobrovskyi <[email protected]>
| // Check that old wl priority class is of type kueue.WorkloadPriorityClass. | ||
| if workload.IsPodPriorityClass(old) { | ||
| return false | ||
| } |
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 now this no need, 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.
for one sec, I thought that your suggestion removed it, my bad, fixed
| Obj(), | ||
| wantChanged: false, | ||
| }, | ||
| "PodPriorityClass added (none -> some) - should not trigger": { |
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 would also be great to add a test case where we change the priority value. It should work only for WorkloadPriorityClass.
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.
this got me thinking, is there a case where Kind changed from PodPriority to WorkloadPriority but uses same name? do we need to cover that?
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, it would be great to cover this case as well.
Co-authored-by: Mykhailo Bobrovskyi <[email protected]>
| util.MustCreate(ctx, k8sClient, normalWl) | ||
| util.ExpectWorkloadsToHaveQuotaReservation(ctx, k8sClient, cq.Name, normalWl) | ||
|
|
||
| ginkgo.By("Creating a suspended workload WITHOUT priority class") |
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 you mean deactivated workload, 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.
Can we add test case here instead? And also apply case from issue.
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 you mean deactivated workload, right?
if I am guessing correctly, in this context you mean:
if I am using .spec.active = true it means deactivated.
if I am using .spec.suspended = true it means suspended?
if so then its deactivated.
What type of PR is this?
/kind bug
What this PR does / why we need it:
Adding a priority class to a workload (none -> some) is now reconciled, and behaving as explained/expected in the ticket
Which issue(s) this PR fixes:
Fixes #8320
Special notes for your reviewer:
Does this PR introduce a user-facing change?
no