[
https://issues.apache.org/jira/browse/YUNIKORN-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860279#comment-17860279
]
Craig Condit commented on YUNIKORN-2703:
----------------------------------------
I think the issue is that after 1.5, the admission controller adding the queue
to pods which don't already have one defined creates a scenario where we can't
distinquish between an explicit "root.default" queue provided by the user (in
which case the 'provided' placement rule would fire) and the queue being set by
the admission controller (which logically shouldn't trigger 'provided'). I
think the fix is:
1) Do NOT set a queue in the admission controller if one was not specified
previously
2) Do NOT pass a queue from the shim to the core unless it was explicitly
requested
3) In the core, treat "no queue" as the lowest priority matching rule, after
all placement rules have fired. This should make the 'provided' rule work
properly in all cases.
> 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: Improvement
> 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
