[
https://issues.apache.org/jira/browse/YUNIKORN-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763520#comment-17763520
]
Wilfred Spiegelenburg commented on YUNIKORN-1951:
-------------------------------------------------
I looked at both PRs and agree with Craig. The calculation needs to take into
account the fact that there might not be a guarantee in the whole queue
hierarchy. If no guarantee is set we should not even attempt preemption no
matter what the max is etc.
When we check if the queue is within guaranteed we should exit directly if we
have no guaranteed set at all.
> Queues with only max resource set shouldn't trigger preemption
> --------------------------------------------------------------
>
> Key: YUNIKORN-1951
> URL: https://issues.apache.org/jira/browse/YUNIKORN-1951
> Project: Apache YuniKorn
> Issue Type: Bug
> Components: core - scheduler
> Reporter: Hsuan Zong Wu
> Assignee: Hsuan Zong Wu
> Priority: Major
> Labels: pull-request-available
>
> The function QueuePreemptionSnapshot.IsWithinGuaranteedResource() is used to
> verify that a queue can trigger preemption by checking that all used
> resources are within guarantees. Since not all resources may be specified in
> a guarantee, we (properly) ignore unspecified resources. For example, if only
> memory is set with a guarantee, then only memory is evaluated to determine if
> a queue is within guaranteed limits. Things like pods, cpu, ephemeral storage
> are not evaluated. So far so good.
> However, if no guarantees exist at all (on either the leaf queue or any
> parent of it), this logic results in the queue being *always* within
> guaranteed limits. This is incorrect. Instead, the queue should be made
> ineligible to trigger preemption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
