-
Notifications
You must be signed in to change notification settings - Fork 276
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
TAS: introduce scheduler-level tests #3361
TAS: introduce scheduler-level tests #3361
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
0660f4e
to
39bb53e
Compare
39bb53e
to
441cecd
Compare
if in.Spec.Preemption != nil { | ||
c.Preemption = *in.Spec.Preemption | ||
} else { | ||
c.Preemption = defaultPreemption | ||
} | ||
|
||
c.UpdateWithFlavors(resourceFlavors) |
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.
FYI: The new unit test discovered this subtle bug - the UpdateWithFlavors requires the Preemption to be set, so that the check for Preemption.withinClusterQueue != "Never" is correct (otherwise it is "", so considered not equal, and the CQ is inactivated).
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 checked this bug in the flow (c.UpdateWithFlavors()
-> c.updateQueueStatus()
-> c.isTASViolated()
) and (c.updateWithAdmissionChecks()
-> c.updateQueueStatus()
-> c.isTASViolated()
).
@@ -805,51 +801,6 @@ func TestFindTopologyAssignment(t *testing.T) { | |||
}, | |||
}, | |||
}, | |||
"don't double-count TAS pods when computing the capacity": { |
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.
FYI this scenario is moved to the new suite as "workload gets scheduled as the usage of TAS pods and workloads is not double-counted", since it was tricky to account for the Workloads' usage in this setup (see comment below). So the test used to create a "TAS" Pod, but it didn't belong to any TAS workload. The new suite allows to account for Workloads and Pods.
/cc @mbobrovskyi |
/lgtm Thanks! |
LGTM label has been added. Git tree hash: 05b191c81bebb6a951f3d178648642045d9b82eb
|
if in.Spec.Preemption != nil { | ||
c.Preemption = *in.Spec.Preemption | ||
} else { | ||
c.Preemption = defaultPreemption | ||
} | ||
|
||
c.UpdateWithFlavors(resourceFlavors) |
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 checked this bug in the flow (c.UpdateWithFlavors()
-> c.updateQueueStatus()
-> c.isTASViolated()
) and (c.updateWithAdmissionChecks()
-> c.updateQueueStatus()
-> c.isTASViolated()
).
|
||
ctx, cancel := context.WithTimeout(ctx, queueingTimeout) | ||
go qManager.CleanUpOnContext(ctx) | ||
defer cancel() |
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.
defer cancel() | |
t.Cleanup(cancel()) |
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.
EventType: corev1.EventTypeNormal, | ||
}, | ||
}, | ||
}, |
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 if more than one flavor was assigned to a single resource like
} else if *result != v.Name { |
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 check was added proactively. I'm not sure how to trigger it e2e (or if this is possible). I will investigate separately, added a point in the spreadsheet as "Investigate if possible to have two flavors for the same resource"
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.
Thank you for adding this to the sheet.
* TAS: introduce scheduled-level tests * some test cleanups
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
To do not work-around accounting for TAS pods and workloads.
Which issue(s) this PR fixes:
Part of #2724
Special notes for your reviewer:
This was ticked as "Account for usage from TAS workloads in the unit tests for cache" in the spreadsheet.
I'm going to expand the tests in follow up tasks.
I moved already the most "workaround"-ish test, but I could move tests in the future, let me know.
Does this PR introduce a user-facing change?