[ 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