-
Notifications
You must be signed in to change notification settings - Fork 479
Update PriorityClass only for WorkloadPriorityClassSource. #7299
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 PriorityClass only for WorkloadPriorityClassSource. #7299
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
39276ef to
30790cd
Compare
30790cd to
ce58bf5
Compare
|
/hold |
ce58bf5 to
7359d08
Compare
|
/unhold |
|
/cc @mimowo |
| // update workload priority if job's label changed | ||
| if WorkloadPriorityClassName(object) != wl.Spec.PriorityClassName { | ||
| // Update workload priority if job's label changed. | ||
| if wl.Spec.PriorityClassSource == constants.WorkloadPriorityClassSource && WorkloadPriorityClassName(object) != wl.Spec.PriorityClassName { |
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.
Isn't wl.Spec.PriorityClassSource == constants.WorkloadPriorityClassSource implied? How would the WorkloadPriorityClassName(object) change if WorkloadPriorityClassSource wasn't used?
Do you mean a user manually changing the Workload object, or it could happen somehow by mutating the Job?
I'm asking cause I want to make the scenario clear in the release notes. For now it seems like impossible scenario for a user to face (at least not clear to me).
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.
No, it happens even if nothing has changed. We’re checking whether WorkloadPriorityClassName(object) != wl.Spec.PriorityClassName. But what if we have PodPriorityClassSource? In that case, "" != "test-priority-class", which evaluates to true every time, so the workload gets updated on each reconciliation.
You can check the unit test I created — if we revert this change, we’ll see an event with the UpdatedWorkload reason during every reconciliation.
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 see, so this is a serious bug. I think for users using WorkloadPriorityClass it is safe, it is actually problematic for Pod's priority users.
We should reflect that better in the release note for sure.
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 for users using WorkloadPriorityClass it is safe
Yes, you’re right — this bug affects only Pod priority users.
|
proposal: When was that introduced, probably only 0.14 is affected? |
|
@mimowo: once the present PR merges, I will cherry-pick it on top of In response to this:
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-sigs/prow repository. |
It was introduced in #5197. I think we should also cherry-pick it to release-0.13. |
|
/cherrypick release-0.13 |
|
@mbobrovskyi: once the present PR merges, I will cherry-pick it on top of In response to this:
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-sigs/prow repository. |
|
@mbobrovskyi Can I also ask how you noticed this bug / how we can reproed it for older versions without the fix? Checking which priority classes we use. |
Just create a job with a Pod PriorityClass. I also added a unit test — you can check it. It doesn’t require any changes. From the user’s perspective, they will only see new events, which could be confusing since nothing actually changed. We are updating the same workload with the same values. |
|
Thanks 👍 |
|
LGTM label has been added. Git tree hash: 10374a1f3dc510c9cc03dd28a31937f2ab21b21e
|
|
[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 |
|
@mimowo: new pull request created: #7302 In response to this:
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-sigs/prow repository. |
|
@mbobrovskyi: new pull request created: #7303 In response to this:
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-sigs/prow repository. |
|
The cherry picks need to be prepared manually |
…dPriorityClassSource. (#7306) * Update PriorityClass only for WorkloadPriorityClassSource. * Fix after cherry-pick.
…dPriorityClassSource. (#7305) * Update PriorityClass only for WorkloadPriorityClassSource. * Fix after cherry-pick.
What type of PR is this?
/kind bug
What this PR does / why we need it:
Update PriorityClass only for WorkloadPriorityClassSource.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?