-
Notifications
You must be signed in to change notification settings - Fork 479
Differentiate podsets quota in messages presented to user #7232
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
Differentiate podsets quota in messages presented to user #7232
Conversation
|
Welcome @iomarsayed! |
|
Hi @iomarsayed. 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-sigs/prow repository. |
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
|
/ok-to-test |
|
@iomarsayed please make sure CLA is signed |
| status.appendf("insufficient quota for %s in flavor %s, request > maximum capacity (%s > %s)", | ||
| fr.Resource, fr.Flavor, resources.ResourceQuantityString(fr.Resource, val), resources.ResourceQuantityString(fr.Resource, maxCapacity)) | ||
| if totalRequestQuota > maxCapacity { | ||
| status.appendf("insufficient quota for %s in flavor %s, remaining podset requests (%s) + current podset request (%s) > maximum capacity (%s)", |
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 seems like a user-facing change, we could handle it as a bugfix, but please add a unit test to demonstrate the new message. I think this could be tested in scheduler_test.go by asserting using wantEvents.
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.
Okay, I will modify it as a bugfix, and will also add a unit test for that!
|
the release not under "Does this PR introduce a user-facing change?" needs to be inside the release-note block as if you create a new PR |
|
@iomarsayed: The label(s) 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. |
|
@iomarsayed: The label(s) 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. |
| } | ||
| } | ||
|
|
||
| resourceLimit := podSets[0].Template.Spec.Containers[0].Resources.Limits[rName] |
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 Kueue doesn't make decisions based on "Limits", so I'm surprised by this code.
I think (by might be missing something) we should just pass val and assignmentUsage[fr] as separate parameters, here:
valis the "current PodSet usage"assignmentUsage[fr]is the usage coming from the previously considered PodSets
/hold
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 want first to confirm that no changes to the actual logic/decisions are done in this PR and all are only adjusting messages logged to the user.
From my understanding, In case of multi-replica "val" refers to the total podset quota, while I am concerned with podset quota for a single replica. So this was my resort. We want to tell the user only if a single-replica podset quota > current resource flavor, because that's how they are actually assigned (as a single replica not the total replica quota).
If that's incorrect let me know.
Thanks for your clarification though it made realize I have to adjust the message because it wasn't incorrectly showing the previous podset usage.
The new message layout is based on @gabesaba suggestion though:
#4134 (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.
I want first to confirm that no changes to the actual logic/decisions are done in this PR and all are only adjusting messages logged to the user.
Yes, but I'm sceptical we should base the message on the "limits". The name podSetQuota is also rather confusing. We declare quota at the CQ level. PodSets are more associated with "usage", calculated based on "requests".
From my understanding, In case of multi-replica "val" refers to the total podset quota, while I am concerned with podset quota for a single replica. So this was my resort. We want to tell the user only if a single-replica podset quota > current resource flavor, because that's how they are actually assigned (as a single replica not the total replica quota).
If that's incorrect let me know.
I think there is room for improvement for sure, but I think the source of the problem is that currently we use val+assignmentUsage[fr] which does not allow for more detailed message. So my proposal is to also keep the same logic, just pass val and assignmentUsage[fr] as separate params.
The new message layout is based on @gabesaba suggestion though: #4134 (comment)
Yeah, this proposal reads ok. I would just tweak slightly as maybe "previous requests" would not be clear, so: requests for previously considered PodSets (%s) + request for current PodSet (%s) > maximum capacity (%s).
In any case, the usage for comparision comes from "Requests", not "limits".
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.
Okay so, I have made the following changes:
- Adjusted the message to be clear as you suggested.
- You are correct! I have corrected the comparison to be against requests, to match the actual logic happening (although it is concerning why a total podset quota including all replicas is compared to a resource flavor and not per replica, but this should be a separate discussion). I have separated the variables, and renamed the function parameters, because they were very vague (specifically "val") while keeping changes as minimum as possible.
- Adjusted test cases reflecting the changes in the message logs.git statu
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 overall, just added a small follow up comment on naming
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.
/unhold
|
/test pull-kueue-test-unit-main |
7b23bd9 to
992a55a
Compare
| // If the flavor doesn't satisfy limits immediately (when waiting or preemption | ||
| // could help), it returns a Status with reasons. | ||
| func (a *FlavorAssigner) fitsResourceQuota(log logr.Logger, fr resources.FlavorResource, val int64, rQuota schdcache.ResourceQuota) (preemptionMode, int, *Status) { | ||
| func (a *FlavorAssigner) fitsResourceQuota(log logr.Logger, fr resources.FlavorResource, usageQuota int64, requestQuota int64, rQuota schdcache.ResourceQuota) (preemptionMode, int, *Status) { |
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.
| func (a *FlavorAssigner) fitsResourceQuota(log logr.Logger, fr resources.FlavorResource, usageQuota int64, requestQuota int64, rQuota schdcache.ResourceQuota) (preemptionMode, int, *Status) { | |
| func (a *FlavorAssigner) fitsResourceQuota(log logr.Logger, fr resources.FlavorResource, assumedUsage int64, requestedUsage int64, rQuota schdcache.ResourceQuota) (preemptionMode, int, *Status) { |
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.
Done just now
|
/release-note-edit |
|
Thanks 👍 |
|
@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. |
|
LGTM label has been added. Git tree hash: 7ebca5b4b76a8dc5e9faeaa338143e8637002451
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: iomarsayed, 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: #7293 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. |
|
@mimowo: new pull request created: #7294 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. |
|
/release-note-edit |
|
/remove-kind cleanup |
What type of PR is this?
/kind bug
What this PR does / why we need it:
During flavor assignment, misleading messages presented to user where only the total remaining requested quota of all podsets is compared to capacity.
Now, quota of current podset will be distinguished in messages.
Which issue(s) this PR fixes:
Fixes #4134
Does this PR introduce a user-facing change?