Add Test results for v1.19 #9
Conversation
yashdesai93
force-pushed
the
vmware/topic/dy/result_1.19
branch
3 times, most recently
from
314e5a9 to
466b3fd
Compare
known-test-failures.md
Outdated
|
|
||
| ### What's the issue? | ||
|
|
||
| Supervisor cluster does not support Pod priorities and preemption. | ||
|
|
||
| ### What's the impact? | ||
|
|
||
| PriorityClass is ignored in the Supervisor cluster. | ||
|
|
||
| ### Are there workarounds? | ||
|
|
||
| No. PriorityClass, if specified, will be ignored. |
There was a problem hiding this comment.
Looks good to me.
Would be great if Ben and/or Pranshu also took a look.
There was a problem hiding this comment.
I think it would be a bit incorrect to say that both priority and preemption are unsupported and PriorityClass is ignored.
Pod priority also impacts the scheduling order of the pods and this works in the Supervisor cluster as well. Essentially, when Pod priority is enabled, the scheduler orders pending Pods by their priority and a pending Pod with higher priority is placed ahead of other pending Pods with lower priority in the scheduling queue. As a result, the higher priority Pod may be scheduled sooner than Pods with lower priority if its scheduling requirements are met. If such Pod cannot be scheduled, scheduler will continue and tries to schedule other lower priority Pods.
This part of PodPriority impacting the scheduling order leverages K8s scheduler's logic of evaluating pods in the order of their priority and hence it works as-is in the SV clusters and PriorityClass is not ignored.
What does not work (or it'd be more accurate to say that what hasn't been evaluated and the behavior is undeterministic) is the preemption of a lower priority pod when a higher priority pod cannot be scheduled. If no Node is found that satisfies all the specified requirements of a Pod, preemption logic is triggered for the pending Pod and it is this "preemption logic" that has not been evaluated in the SV clusters.
There was a problem hiding this comment.
@pranshujain28 Thanks for this detailed explanation. I would suppose that the reason this has come up is because we fail a test around pre-emption logic. It would be good if we could meet to agree on a crisp explanation. @vshetty Is this also an issue for versions > 1.19?
There was a problem hiding this comment.
It is an issue > 1.19 as well, the tests were added in 1.19.
There was a problem hiding this comment.
@corrieb this is an issue for > 1.19 as well.
@pranshujain28 can you help come up with a small write-up for this?
Add test results for v1.19 along with a known-tests-failures.md for this version. Also add the skipped_tests.xml to point out tests that were skipped
yashdesai93
force-pushed
the
vmware/topic/dy/result_1.19
branch
from
466b3fd to
b60dcce
Compare
Add test results for v1.19 along with a known-tests-failures.md for this version.