Not planned
Description
Background
Scheduler framework provides extension hooks to scheduler plugins. k/k usually does a good job to ensure all in-tree plugins adheres to framework changes in each release, but it's not always the case for out-of-tree plugins. For example, #115583 (comment) reveals a case that we wanted to make in-tree plugin more efficient, but mistakenly breaks the compatibility of out-of-tree plugins. Per suggestion in #117194 (comment), this umbrella issue is created to ensure adequate test coverage of potential paths on each extension point that out-of-tree plugins may exercise.
Note: when composing tests, think loud on other patterns of using a particular extension point.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Closed
Activity
k8s-ci-robot commentedon Apr 11, 2023
This issue is currently awaiting triage.
If a SIG or subproject determines this is a relevant issue, they will accept it by applying the
triage/acceptedlabel and provide further guidance.The
triage/acceptedlabel can be added by org members by writing/triage acceptedin a comment.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/test-infra repository.
Huang-Wei commentedon Apr 11, 2023
/kind feature
/sig scheduling
alculquicondor commentedon Apr 11, 2023
Each of the tests we add should have a deliberation. We shouldn't simply accept the way an out-of-tree plugin is using the scheduling framework if we have to sacrifice in-tree plugins performance or if it significantly adds maintenance burden.
That said, I'm in favor of the test for #115583 (comment)
Huang-Wei commentedon Apr 11, 2023
Yes, before working on a PR, each upcoming test needs to describe the intention specifically under this issue.
sanposhiho commentedon Apr 11, 2023
/assign
sanposhiho commentedon May 5, 2023
Not sure if it's the right place to mention, but I recently feel we, sooner or later, need to have the performance test (in scheduler_perf or
Benchmark_XXX) to ensure no performance degradation on enqueueing in various scenario, given we already have PreEnqueue, and we'll have wise-enqueueing via my proposal or pohly's one.Huang-Wei commentedon May 8, 2023
A function level BenchmarkXYZ test may not be able to test an e2e flow. We can craft new tests in scheduler_perf to cover 1) basic scenario that not involves in-flight pod, and 2) scenario that involves in-flight pod (e.g., DRA specific one). Then with the results of 1) and 2), it can give us more clues how to proceed.
kerthcet commentedon May 8, 2023
Poor points, shouldn't this be ensured in scheduler-plugins repo, in kubernetes, we can fake new plugins in tests to make sure this not happen.
28 remaining items