[
https://issues.apache.org/jira/browse/YUNIKORN-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860809#comment-17860809
]
Craig Condit edited comment on YUNIKORN-2703 at 6/28/24 12:35 PM:
------------------------------------------------------------------
[~mitdesai], in your example:
{code:java}
placementrules:
- name: tag
value: namespace
- name: fixed
value: root.default {code}
This hides the problem in your approach. If instead we consider this:
{code:java}
placementrules:
- name: tag
value: namespace
- name: provided
- name: fixed
value: root.fixed{code}
If we add a queue for "root.default" in the admission controller, than the
fixed rule can *never* match, because the provided rule will always fire
(assuming the namespace tag doesn't). This is why we need to ignore the default
queue configuration in the admission controller and not set a queue. Then the
scheduler is able to differentiate between an explicit queue (that happens to
have the default name) from no queue at all, as these are distinct cases.
I stand by my original conclusion as to what steps need to be taken to fix this
issue. I also think we should target this for 1.5.2, as it is a serious
regression introduced in 1.5.0 with the default queue logic in the admission
controller. That is where the breakage occurs.
was (Author: ccondit):
[~mitdesai], in your example:
{code:java}
placementrules:
- name: tag
value: namespace
- name: fixed
value: root.default {code}
This hides the problem in your approach. If instead we consider this:
{code:java}
placementrules:
- name: tag
value: namespace
- name: provided
- name: fixed
value: root.fixed{code}
If we add a queue for "root.default" in the admission controller, than the
fixed rule can *never* match, because the provided rule will always fire
(assuming the namespace tag doesn't). This is why we need to ignore the default
queue configuration in the admission controller and not set a queue. Then the
scheduler is able to differentiate between an explicit queue (that happens to
have the default name) from no queue at all, as these are distinct cases.
I stand by my original conclusion as to what steps need to be taken to fix this
issue.
> Scheduler does not honor default queue setting from the ConfigMap
> -----------------------------------------------------------------
>
> Key: YUNIKORN-2703
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2703
> Project: Apache YuniKorn
> Issue Type: Bug
> Components: shim - kubernetes
> Reporter: Mit Desai
> Assignee: Mit Desai
> Priority: Major
>
> YUNIKORN-1650 added an override for default queue name in the config map to
> solve for the scenario where the provided placement rule is evaluated before
> other rules.
> Scheduler also adds a default queue if the pod labels or annotations does not
> define a queue name. Because this happens before the placement rules are
> evaluated, we end up in the same situation of applications getting placed in
> the default queue and ignoring all other placement rules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: issues-h...@yunikorn.apache.org
