Skip to content

Commit

Permalink
[YUNIKORN-2932] Update local dashboard url in Dev Environment Setup (#…
Browse files Browse the repository at this point in the history
…497)

Closes: #497

Signed-off-by: Yu-Lin Chen <[email protected]>
  • Loading branch information
Michael authored and chenyulin0719 committed Oct 29, 2024
1 parent 293b7b1 commit 4840329
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions docs/design/scheduler_configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,9 +48,9 @@ Scheduler configuration as currently identified

Configuration to consider:
* Assign multiple containers in one go: use case is bin packing, don’t spread an application over large number of nodes. Needs to become configurable.
* Pre-emption related configuration:
* threshold: do not pre-empt from a queue if the cluster load is below a certain threshold.
* Interval: pause between pre-emption checks
* Preemption related configuration:
* threshold: do not preempt from a queue if the cluster load is below a certain threshold.
* Interval: pause between preemption checks
## Queue Configuration
### Queue Definition
On startup the scheduler will load the configuration for the queues from the provided configuration file after initialising the service. If there is no queue configuration provided the scheduler should start up with a simple default configuration which performs a well documented default behaviour.
Expand Down Expand Up @@ -82,7 +82,7 @@ The queue as defined in the configuration will be assigned a queue type. This ca

Access control lists provide a split between submission permission and administration permissions. Submission access to a queue allows an application to be submitted to the queue by the users or groups specified. The administration permissions allows submission to the queue plus the administrative actions. Administrative actions are currently limited to killing an application and moving an application to a different queue.

Access control lists are checked recursively up to the root of the tree starting at the lowest point in the tree. In other words when the access control list of a queue does not allow access the parent queue is checked. The checks are repeated all the way up to the root of the queues.
Access control lists are checked recursively up to the root of the tree starting at the lowest point in the tree. In other words, when the access control list of a queue does not allow access, the parent queue is checked. The checks are repeated all the way up to the root of the queues.

On each queue, except the root queue, the following properties can be set:
* QueueType:
Expand All @@ -95,7 +95,7 @@ On each queue, except the root queue, the following properties can be set:
* Queue Permissions:
* SubmitACL (ACL)
* AdminACL (ACL)
* Pre emption setting:
* Preemption setting:
* PreEmptionAllowed (boolean)
* Application sort algorithm:
* ApplicationSortPolicy (enumeration: fair, fifo)
Expand All @@ -115,7 +115,7 @@ Applications are run by a user could run in one or more queues. The queues can h
From an administrative perspective setting a limit of the resources that can be used by a specific user can be important. In this case a user is broadly defined as the identity that submits the application. This can be a service or a person, from a scheduling perspective there is no difference.
User limits can prevent a take over of a queue or the cluster by a misbehaving user or application. From a multi tenancy perspective user limits also allows for sharing or subdivision of resources within the tenancy however that is defined.

Adding user based limits will allow the cluster administrators to control the cluster wide resource usage of a user:
Adding user-based limits will allow the cluster administrators to control the cluster-wide resource usage of a user:
* Running Application limit:
* Maximum (integer)
* Resource setting:
Expand Down

0 comments on commit 4840329

Please sign in to comment.