-
Notifications
You must be signed in to change notification settings - Fork 501
Flavor Fungibility Prefers Fit over NoBorrow #6132
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
Conversation
|
Skipping CI for Draft Pull Request. |
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
| for _, candidate := range candidates { | ||
| revertRemoval := cq.SimulateUsageRemoval(candidate.WorkloadInfo.Usage()) | ||
| defer revertRemoval() | ||
| } |
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 use SimulateWorklaodRemoval?
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. But we have to iterate over the candidates anyway because they are of type Target and we need WorkloadInfo. With SimulateWorkloadRemoval we don't have to get the WorkloadInfo.Usage() so it should be better.
| if len(candidates) == 0 { | ||
| return preemptioncommon.NoCandidates | ||
| return preemptioncommon.NoCandidates, borrowAfterPreemptions | ||
| } |
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 this clause come before usage removal? on line 50?
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 need to calculate the borrowing level before this (even if there are no candidates) because we return it. And before that calculation we have to remove the usage of the candidates (if there are any). So, this is why its here.
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.
Does borrowing level matter if it is NoFit (which is implied by 0 candidates, 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.
It does not matter. If the workload does not fit, the borrowAfterPreemptions will be the maximum distance. Do you suggest it makes more sense to return something else?
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 I finally understood what you mean. Updated the code.
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 take it back. Changing the borrowing for NoCandiates makes some integrations tests to fail. I reverted the change. I'll investigate why is that but in the meantime can it stay as it is?
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.
Once investigated please also add a unit test which demonstrates why this needs to be the wait it is. So that it is much easier to avoid the trap in the future.
|
/hold |
Co-authored-by: gabesaba <[email protected]>
|
@pajakd please mark all addressed comments as resolved and update the release note |
Co-authored-by: Michał Woźniak <[email protected]>
|
/lgtm thank you! |
|
LGTM label has been added. DetailsGit tree hash: a68c4aa2a68c2fd06ffe2058e2b15a0a81d171ad |
| func preferToAvoidBorrowing(fungiblityConfig kueue.FlavorFungibility) bool { | ||
| return (fungiblityConfig.WhenCanBorrow == kueue.TryNextFlavor && fungiblityConfig.WhenCanPreempt == kueue.Preempt) || | ||
| (fungiblityConfig.WhenCanBorrow == kueue.TryNextFlavor && fungiblityConfig.WhenCanPreempt == kueue.TryNextFlavor) | ||
| } |
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.
non-blocking nit: Since now the function simplifies to fungiblityConfig.WhenCanBorrow == kueue.TryNextFlavor can you inline?
|
/remove-kind api-change |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mimowo, pajakd The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* Allow to avoid borrowing in flavor fungibility * Update comment * Update comment * Update comment * Typo fix * Fix tests * Fix typo * Update pkg/scheduler/flavorassigner/flavorassigner.go Co-authored-by: gabesaba <[email protected]> * Address comments * Fix a whitespace * Fix tests * Address comments * Avoid -> prefer * Strategy -> policy * Update the defaults and validation * Fix * Allow empty selection policy * Fix whitespaces * Fix unit test * Update apis/kueue/v1beta1/clusterqueue_types.go Co-authored-by: Michał Woźniak <[email protected]> * Fix errors * Revert API + add feature gate * Cleanup * Cleanup * Simplify the preference check * Additional integration tests * Update pkg/features/kube_features.go Co-authored-by: Michał Woźniak <[email protected]> * Earlier check for 0 candidates * Fix tests * Remove reliance on FS * Fix test --------- Co-authored-by: gabesaba <[email protected]> Co-authored-by: Michał Woźniak <[email protected]>
What type of PR is this?
/kind feature
What this PR does / why we need it:
Some of the users would like to define a different preference when selecting a flavor in flavor fungibility. Currently we always try to minimize preemptions. Sometimes it means that an incoming high-priority workload would choose a flavor in which it has to borrow (because its nominal quota is in use or borrowed). A workload that is borrowing is at risk of being preempted which may be undesirable for high-priority workloads so it might be better for it to preempt and be scheduled in a flavor that does not require borrowing.
This PR adds a feature gate
FlavorFungibilityImplicitPreferenceDefault. When the feature gate is enabled, it infers the preference (borrowing or preemption) based on the FavorFungibilityStrategy. More precisely in two cases:WhenCanPreempt = PreemptandWhenCanBorrow = TryNextFlavorWhenCanPreempt = TryNextFlavorandWhenCanBorrow = TryNextFlavorflavor assigner will prioritize flavors that require preemption over ones that require borrowing. In all other cases, borrowing will be prioritized.
KEP changes will be added in a separate PR.
Which issue(s) this PR fixes:
Fixes #5424
Special notes for your reviewer:
Does this PR introduce a user-facing change?