-
Notifications
You must be signed in to change notification settings - Fork 479
feat: include more detailed preemption information in flavor attempt events #8024
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
feat: include more detailed preemption information in flavor attempt events #8024
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
|
/cc @mbobrovskyi |
a8489ac to
c9777aa
Compare
|
/assign @pajakd |
3232203 to
8120d29
Compare
mbobrovskyi
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
Thank you!
|
LGTM label has been added. Git tree hash: 4d82f3da79961e33f3c41b42fdb963979e244ae9
|
8120d29 to
9bb800c
Compare
|
/lgtm |
|
LGTM label has been added. Git tree hash: 2d97397e46924187e0c4372262c880809617157e
|
|
cc: @mimowo |
|
@mykysha is this correct? In particular the example "Before" ? |
| case reclaim: | ||
| return ptr.To(preemptioncommon.Reclaim) | ||
| default: | ||
| return nil // preemptionMode has non-preemption values that do not address preemption. |
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 don't understand the comment TBH. Is it to say "there are no other options"?
If so I would follow the pattern as above in this function (it is confusing to see two functions side-by-side one returning panic one nil): https://github.com/kubernetes-sigs/kueue/pull/8024/files#diff-0870ec2c0ea330a7d087a6ef599905bf9b7164a0dd889d1b00ba17c31a1bfd05R429
Unless I'm missing something which might be, but then please rephrase the comment to make it more clear.
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.
Changing from preemptioncommon.PreemptionPossibility to preemptionMode is safe, because all the PreemptionPossibility fields have their counterparts, but changing back not so as we introduce non-preemption related fit and noFit to the preemptionMode. I can change return nil to a panic message, but I'm not sure that this is needed.
Perhaps something like
case noFit, fit:
return nil
default:
panic(fmt.Sprintf("illegal PreemptionPossibility: %d", preemptionPossibility))
would be better?
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 we have preemptionPossibility -> preemptionMode -> preemptionPossibility that is weird. Would it be possible to eliminate the preemptionMode entirely?
It is not a question about this PR, but I want to get your view on that since you researched the code recently.
For this PR I would go with, I assume you meant preemptionMode rather than possibilty here:
default:
panic(fmt.Sprintf("unexpected preemptionMode: %d", mode))
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.
Ok, or alternatively stay with
case noFit, fit:
return nil
default:
panic(fmt.Sprintf("illegal preemptionMode: %d", preemptionMode))but remove this guard chack https://github.com/kubernetes-sigs/kueue/pull/8024/files#diff-0ea412b6476f3b5faaa7e3ad1fb3ded2e8c568df3c84474c0c576df47223c56cR72-R74
Keeping the guards at both levels makes some code dead.
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 preemptionMode can be modified to contain both the FlavorAssignmentMode as well as the PreemptionPossibility and we would not need to have so many conversions. Another possibility is to add missing values to the FlavorAssignmentMode, but this change would be more intrusive.
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.
sgtm, as mentioned I'm good to keep it for future depending how the code evolves
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.
Removed the guard and went with the case nofit, fit: approach. Making changes to the preemptionMode would potentially remove the conversion altogether, but that could be addressed in a separate PR
|
Before is definitely correct, but we can also change after to better show that Reclaim and NoCandidates are added, perhaps like ? |
|
sgtm, updating: |
|
|
||
| existingPreemption := existing.PreemptionPossibility | ||
| if at.PreemptionPossibility != nil && (existingPreemption == nil || *at.PreemptionPossibility < *existingPreemption) { | ||
| existing.PreemptionPossibility = at.PreemptionPossibility |
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 error prone and confusing to introduce the variable existingPreemption, and use it only for "read" but for "update" using the underlying existing variable.
Either don't introduce the new variable just update existing, or update the local copy. Generally mutating the local copy than the original pointer is safer, but this code already updates the underlying copy, just in a tricky fashion.
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.
Changed here, now only the copy gets updated
9bb800c to
18af99b
Compare
|
/lgtm |
|
LGTM label has been added. Git tree hash: e227c17e8643c0e5c4c38583bafa564f1e66378f
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mbobrovskyi, mimowo, mykysha 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 feature
What this PR does / why we need it:
Display more detailed information on preemption in the flavor assignment attempt block in events
Follow-up for #7646
Which issue(s) this PR fixes:
Part of #7137
Special notes for your reviewer:
Does this PR introduce a user-facing change?