[incubator-yunikorn-site] branch master updated: [YUNIKORN-395] Adding node sorting policy texts (#18)

[ww...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

wwei pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-yunikorn-site.git


The following commit(s) were added to refs/heads/master by this push:
     new 2b0f39d  [YUNIKORN-395] Adding node sorting policy texts (#18)
2b0f39d is described below

commit 2b0f39da0004a7aa98af424479aa903e2f2686ac
Author: Adam Antal <ad...@cloudera.com>
AuthorDate: Fri Sep 4 06:46:36 2020 +0200

    [YUNIKORN-395] Adding node sorting policy texts (#18)
---
 docs/user_guide/queue_config.md | 28 +++++++++++-----------------
 1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/docs/user_guide/queue_config.md b/docs/user_guide/queue_config.md
index 30f213b..007d5a0 100644
--- a/docs/user_guide/queue_config.md
+++ b/docs/user_guide/queue_config.md
@@ -42,21 +42,7 @@ By default we use the file called `queues.yaml` in our deployments.
 The filename can be changed via the command line flag `policyGroup` of the scheduler.
 Changing the filename must be followed by corresponding changes in the deployment details, either the `configmap` or the file included in the docker container.
 
-Here is a sample configuration file:
-
-```yaml
-partitions:
-  - name: default
-    placementrules:
-      - name: tag
-        value: namespace
-        create: true
-    queues:
-      - name: root
-        submitacl: '*'
-```
-
-this configuration defines one single partition `default`, and it automatically maps namespaces to an dynamical queue under the root queue. 
+The example file for the configuration is located in the scheduler core's [queues.yaml](https://github.com/apache/incubator-yunikorn-core/blob/master/config/queues.yaml).  
 
 ## Partitions
 Partitions are the top level of the scheduler configuration.
@@ -81,19 +67,25 @@ The queues configuration is explained below.
 Optionally the following keys can be defined for a partition:
 * [placementrules](#placement-rules)
 * [limits](#limits)
+* nodesortpolicy
 * preemption
 
 Placement rules and limits are explained in their own chapters
+
+The `nodesortpolicy` defines the way the nodes are sorted for the partition.
+Details on the values that can be used are in the [sorting policy](sorting_policies.md#node-sorting) documentation.
+
 The preemption key can currently have only one sub key: _enabled_.
 This boolean value defines the preemption behaviour for the whole partition.
 
 The default value for _enabled_ is _false_.
 Allowed values: _true_ or _false_, any other value will cause a parse error.
 
-Example `partition` yaml entry with _preemption_ flag:
+Example `partition` yaml entry with _preemption_ flag set and a `nodesortpolicy` of _fair_:
 ```yaml
 partitions:
   - name: <name of the partition>
+    nodesortpolicy: fair
     preemption:
       enabled: true
 ```
@@ -173,7 +165,8 @@ The `queues` entry is a recursive entry for a queue level and uses the exact sam
 The `properties` parameter is a simple key value pair list. 
 The list provides a simple set of properties for the queue.
 There are no limitations on the key or value values, anything is allowed.
-Currently the property list is not used in the scheduler and is only provided for future expansion like the option to turn on or off preemption on a queue or define a sorting order specific for a queue.  
+Currently, the property list is only used in the scheduler to define a [sorting order](sorting_policies.md#application-sorting) for a leaf queue.
+Future expansions, like the option to turn on or off preemption on a queue or other sorting policies, would use this same property construct without the need to change the configuration.
 
 Access to a queue is set via the `adminacl` for administrative actions and for submitting an application via the `submitacl` entry.
 ACLs are documented in the [Access control lists](acls.md) document.
@@ -197,6 +190,7 @@ partitions:
 ```
 
 ### Placement rules
+
 The placement rules are defined and documented in the [placement rule](placement_rules.md) document.
 
 Each partition can have only one set of placement rules defined.