application.sort.policy",id:"applicationsortpolicy",level:4},{value:"application.sort.priority",id:"applicationsortpriority",level:4},{value:"priority.policy",id:"prioritypolicy",level:4},{value:"priority.offset",id:"priorityoffset",level:4},{value:"preemption.policy",id:"preemptionpolicy",level:4},{value:"preemption.delay",id:"preemptiondelay",level:4},{value:"Resources",id:"resources",level:3},{value:"Child Template",id:"child-template",level:3}];function d(e){const n={a:"a",admonition:"admonition",br:"br",code:"code",em:"em",h2:"h2",h3:"h3",h4:"h4",li:"li",ol:"ol",p:"p",pre:"pre",strong:"strong",ul:"ul",...(0,s.R)(),...e.components};return(0,r.jsxs)(r.Fragment,{children:[(0,r.jsxs)(n.p,{children:["The basis for the queue configuration is given in the ",(0,r.jsx)(n.a,{href:"/docs/next/design/scheduler_configuration",children:"configuration design document"}),"."]}),"\n",(0,r.jsxs)(n.p,{children:["This document provides the generic queue configuration.\nIt references both the ",(0,r.jsx)(n.a,{href:"/docs/next/user_guide/acls",children:"Access Control Lists"})," and ",(0,r.jsx)(n.a,{href:"/docs/next/user_guide/placement_rules",children:"Placement rules"})," documentation."]}),"\n",(0,r.jsx)(n.p,{children:"This document explains how to create the partition and queue configuration for the scheduler with examples."}),"\n",(0,r.jsxs)(n.p,{children:["The scheduler relies on the shim to reliably provide user information as part of the application submission.\nThe current shim identifies the user and the groups the user belongs to using the methodology provided in ",(0,r.jsx)(n.a,{href:"usergroup_resolution",children:"User & Group Resolution"}),"."]}),"\n",(0,r.jsx)(n.h2,{id:"configuration",children:"Configuration"}),"\n",(0,r.jsx)(n.p,{children:"The configuration file for the scheduler that is described here only provides the configuration for the partitions and queues."}),"\n",(0,r.jsxs)(n.p,{children:["By default the scheduler reads the ConfigMap section ",(0,r.jsx)(n.code,{children:"queues.yaml"})," for partition and queue configuration. The section name can\nbe changed by updating the ",(0,r.jsx)(n.code,{children:"service.policyGroup"})," ConfigMap entry to be something other than ",(0,r.jsx)(n.code,{children:"queues"}),"."]}),"\n",(0,r.jsxs)(n.p,{children:["The example reference for the configuration is located in the scheduler core's ",(0,r.jsx)(n.a,{href:"https://github.com/apache/yunikorn-core/blob/master/config/queues.yaml",children:"queues.yaml"})," file."]}),"\n",(0,r.jsx)(n.h2,{id:"partitions",children:"Partitions"}),"\n",(0,r.jsx)(n.p,{children:"Partitions are the top level of the scheduler configuration.\nThere can be more than one partition defined in the configuration."}),"\n",(0,r.jsx)(n.p,{children:"Basic structure for the partition definition in the configuration:"}),"\n",(0,r.jsx)(n.pre,{children:(0,r.jsx)(n.code,{className:"language-yaml",children:"partitions:\n - name: application.sort.policy",id:"applicationsortpolicy",level:4},{value:"application.sort.priority",id:"applicationsortpriority",level:4},{value:"priority.policy",id:"prioritypolicy",level:4},{value:"priority.offset",id:"priorityoffset",level:4},{value:"preemption.policy",id:"preemptionpolicy",level:4},{value:"preemption.delay",id:"preemptiondelay",level:4},{value:"Resources",id:"resources",level:3},{value:"Child Template",id:"child-template",level:3}];function d(e){const n={a:"a",admonition:"admonition",br:"br",code:"code",em:"em",h2:"h2",h3:"h3",h4:"h4",li:"li",ol:"ol",p:"p",pre:"pre",strong:"strong",ul:"ul",...(0,s.R)(),...e.components};return(0,r.jsxs)(r.Fragment,{children:[(0,r.jsxs)(n.p,{children:["The basis for the queue configuration is given in the ",(0,r.jsx)(n.a,{href:"/docs/next/design/scheduler_configuration",children:"configuration design document"}),"."]}),"\n",(0,r.jsxs)(n.p,{children:["This document provides the generic queue configuration.\nIt references both the ",(0,r.jsx)(n.a,{href:"/docs/next/user_guide/acls",children:"Access Control Lists"})," and ",(0,r.jsx)(n.a,{href:"/docs/next/user_guide/placement_rules",children:"Placement rules"})," documentation."]}),"\n",(0,r.jsx)(n.p,{children:"This document explains how to create the partition and queue configuration for the scheduler with examples."}),"\n",(0,r.jsxs)(n.p,{children:["The scheduler relies on the shim to reliably provide user information as part of the application submission.\nThe current shim identifies the user and the groups the user belongs to using the methodology provided in ",(0,r.jsx)(n.a,{href:"usergroup_resolution",children:"User & Group Resolution"}),"."]}),"\n",(0,r.jsx)(n.h2,{id:"configuration",children:"Configuration"}),"\n",(0,r.jsx)(n.p,{children:"The configuration file for the scheduler that is described here only provides the configuration for the partitions and queues."}),"\n",(0,r.jsxs)(n.p,{children:["By default the scheduler reads the ConfigMap section ",(0,r.jsx)(n.code,{children:"queues.yaml"})," for partition and queue configuration. The section name can\nbe changed by updating the ",(0,r.jsx)(n.code,{children:"service.policyGroup"})," ConfigMap entry to be something other than ",(0,r.jsx)(n.code,{children:"queues"}),"."]}),"\n",(0,r.jsxs)(n.p,{children:["The example reference for the configuration is located in the scheduler core's ",(0,r.jsx)(n.a,{href:"https://github.com/apache/yunikorn-core/blob/master/config/queues.yaml",children:"queues.yaml"})," file."]}),"\n",(0,r.jsx)(n.h2,{id:"partitions",children:"Partitions"}),"\n",(0,r.jsx)(n.p,{children:"Partitions are the top level of the scheduler configuration.\nThere can be more than one partition defined in the configuration."}),"\n",(0,r.jsx)(n.p,{children:"Basic structure for the partition definition in the configuration:"}),"\n",(0,r.jsx)(n.pre,{children:(0,r.jsx)(n.code,{className:"language-yaml",children:"partitions:\n - name: An example configuration of a queue root.namespaces as a parent queue with limits:
partitions:
- name: default
queues:
- name: namespaces
parent: true
maxapplications: 12
resources:
guaranteed:
{memory: 1G, vcore: 10}
max:
{memory: 10G, vcore: 100}
queues:
- name: level1
maxapplications: 8
resources:
guaranteed:
{memory: 500M, vcore: 5}
max:
{memory: 5G, vcore: 50}
The recovery queue, identified by the name root.@recovery@, is a dynamic queue that is not directly queryable. It is used exclusively during the initialization phase for already running allocations that are part of applications failing placement. Its primary function is to handle tasks that need to be reassigned or recovered without user intervention.
The placement rules are defined and documented in the placement rule document.
Each partition can have only one set of placement rules defined. @@ -269,7 +277,7 @@
As an example:
partitions:
- name: default
placementrules:
- name: provided
create: true
queues:
- name: root
submitacl: '*'
childtemplate:
maxapplications: 10
properties:
application.sort.policy: fifo
resources:
guaranteed:
vcore: 1
memory: 1G
max:
vcore: 20
memory: 600G
queues:
- name: parent
parent: true
childtemplate:
resources:
max:
vcore: 21
memory: 610G
- name: notemplate
parent: true
In this case, root.parent.sales will directly use the child template of parent queue root.parent. By contrast,
-root.notemplate.sales will use the child template set on the queue root since its parent queue root.notemplate inherits the child template from the queue root.