This is an automated email from the ASF dual-hosted git repository. ccondit pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/yunikorn-site.git
The following commit(s) were added to refs/heads/master by this push: new 837d53ab56 [YUNIKORN-2509] Remove state-aware scheduling documentation (#417) 837d53ab56 is described below commit 837d53ab56bd71afe252237e11f72bcf3e5f94dd Author: Craig Condit <ccon...@apache.org> AuthorDate: Wed Mar 20 16:18:46 2024 -0500 [YUNIKORN-2509] Remove state-aware scheduling documentation (#417) Closes: #417 --- docs/api/scheduler.md | 12 ------- .../state_aware_scheduling.md | 0 docs/assets/application-state.png | Bin 136449 -> 105253 bytes docs/assets/k8shim-node-state.png | Bin 52316 -> 0 bytes docs/design/historical_usage_tracking.md | 3 -- docs/design/user_group_manager.md | 6 ++-- docs/developer_guide/scheduler_object_states.md | 12 +------ docs/user_guide/sorting_policies.md | 37 --------------------- sidebars.js | 2 +- 9 files changed, 5 insertions(+), 67 deletions(-) diff --git a/docs/api/scheduler.md b/docs/api/scheduler.md index 1ab0c644ce..677a64a469 100644 --- a/docs/api/scheduler.md +++ b/docs/api/scheduler.md @@ -416,10 +416,6 @@ In the example below there are three allocations belonging to two applications, "time": 1648741409145224000, "applicationState": "Accepted" }, - { - "time": 1648741409145509400, - "applicationState": "Starting" - }, { "time": 1648741409147432100, "applicationState": "Running" @@ -523,10 +519,6 @@ In the example below there are three allocations belonging to two applications, "time": 1648741409145224000, "applicationState": "Accepted" }, - { - "time": 1648741409145509400, - "applicationState": "Starting" - }, { "time": 1648741409147432100, "applicationState": "Running" @@ -675,10 +667,6 @@ Field `uuid` has been deprecated, would be removed from below response in YUNIKO "time": 1648741409145224000, "applicationState": "Accepted" }, - { - "time": 1648741409145509400, - "applicationState": "Starting" - }, { "time": 1648741409147432100, "applicationState": "Running" diff --git a/docs/design/state_aware_scheduling.md b/docs/archived_design/state_aware_scheduling.md similarity index 100% rename from docs/design/state_aware_scheduling.md rename to docs/archived_design/state_aware_scheduling.md diff --git a/docs/assets/application-state.png b/docs/assets/application-state.png index 2af46e96e1..ec1b365b95 100644 Binary files a/docs/assets/application-state.png and b/docs/assets/application-state.png differ diff --git a/docs/assets/k8shim-node-state.png b/docs/assets/k8shim-node-state.png deleted file mode 100644 index 5d5db56a88..0000000000 Binary files a/docs/assets/k8shim-node-state.png and /dev/null differ diff --git a/docs/design/historical_usage_tracking.md b/docs/design/historical_usage_tracking.md index 83d068033c..3e0b447f27 100644 --- a/docs/design/historical_usage_tracking.md +++ b/docs/design/historical_usage_tracking.md @@ -228,7 +228,6 @@ APP_REQUEST = 201 // Request changed APP_REJECT = 202 // Application rejected on create APP_NEW = 203 // Application added with state new APP_ACCEPTED = 204 // State change to accepted -APP_STARTING = 205 // State change to starting APP_RUNNING = 206 // State change to running APP_COMPLETING = 207 // State change to completing APP_COMPLETED = 208 // State change to completed @@ -466,7 +465,6 @@ It serves as a reference for the core scheduler actions that will trigger the ev | APP | REMOVE | REQUEST_CANCEL | RequestID | Removal triggered by application removal | | APP | SET | APP_NEW | | State change: New | | APP | SET | APP_ACCEPTED | | State change: Accepted | -| APP | SET | APP_STARTING | | State change: Starting | | APP | SET | APP_RUNNING | | State change: Running | | APP | SET | APP_COMPLETING | | State change: Completing | | APP | SET | APP_COMPLETED | | State change: Completed | @@ -568,7 +566,6 @@ An application undergoes state transitions, so the following events are generate - Add new application - State change: New - State change: Accepted -- State change: Starting - State change: Running - State change: Completing - State change: Completed diff --git a/docs/design/user_group_manager.md b/docs/design/user_group_manager.md index e70cad961a..cc0685685e 100644 --- a/docs/design/user_group_manager.md +++ b/docs/design/user_group_manager.md @@ -105,11 +105,11 @@ Since placeholders and placeholder timeout can play a role in state changes the ### Running state entry -The application when submitted and placed into a queue is in the _New_ state. At this point there is no allocation or pending request present on the application. After one or more requests, _AllocationAsks_, are added the application moves into an _Accepted_ state. The _Accepted_ state is exited when the first _Allocation_ is added to the application. The application then transitions into the Starting state. +The application when submitted and placed into a queue is in the _New_ state. At this point there is no allocation or pending request present on the application. After one or more requests, _AllocationAsks_, are added the application moves into an _Accepted_ state. The _Accepted_ state is exited when the first _Allocation_ is added to the application. The application then transitions into the Running state. At this point a resource quota would be used by the application and the application should be considered as running from a tracking perspective. This means that the addition of the first _Allocation_ onto the application also must be the trigger point for the increase of the running applications. This trigger point for tracking is when the application is in the _Accepted_ state. This is also the point at which the group for the usage tracking needs to be set as described in the [group li [...] -Note that currently, the application state transition code block in application_state.go updates the application running queue metrics when the application enters _Running_ state. The metric must be updated to be consistent with the above definition of a running application. Linking this back to a state transition the entry into the Starting state should be used. +Note that currently, the application state transition code block in application_state.go updates the application running queue metrics when the application enters _Running_ state. The metric must be updated to be consistent with the above definition of a running application. Linking this back to a state transition the entry into the Running state should be used. ### Running state exit @@ -407,4 +407,4 @@ An example below the approximate output for the groups endpoint for one group: } } ] -``` \ No newline at end of file +``` diff --git a/docs/developer_guide/scheduler_object_states.md b/docs/developer_guide/scheduler_object_states.md index 86cc135aea..48e79703b5 100644 --- a/docs/developer_guide/scheduler_object_states.md +++ b/docs/developer_guide/scheduler_object_states.md @@ -38,14 +38,7 @@ An application can have the following states: * New: A new application that is being submitted or created, from here the application transitions into the accepted state when it is ready for scheduling. The first ask to be added will trigger the transition. * Accepted: The application is ready and part of the scheduling cycle. -On allocation of the first ask the application moves into a starting state. -This state is part of the normal scheduling cycle. -* Starting: The application has exactly one allocation confirmed this corresponds to one running container/pod. -The application transitions to running if and when more allocations are added to the application. -This state times out automatically to prevent applications that consist of just one allocation from getting stuck in this state. -The current time out is set to 5 minutes, and cannot be changed. -If after the timeout expires the application will auto transition to running. -The state change on time out is independent of the number of allocations added. +On allocation of the first ask the application moves into a running state. This state is part of the normal scheduling cycle. * Running: The state in which the application will spend most of its time. Containers/pods can be added to and removed from the application. @@ -118,6 +111,3 @@ The node status changes based on the status provided by the resource manager (sh ### Task ![task state diagram](./../assets/k8shim-task-state.png) - -### Node -![node state diagram](./../assets/k8shim-node-state.png) diff --git a/docs/user_guide/sorting_policies.md b/docs/user_guide/sorting_policies.md index f5de40af04..88358bc29f 100644 --- a/docs/user_guide/sorting_policies.md +++ b/docs/user_guide/sorting_policies.md @@ -86,43 +86,6 @@ All resources defined on the application will be taken into account when calcula The result is that the resources available are spread equally over all applications that request resources. -### StateAwarePolicy -Short description: limit of one (1) application in Starting or Accepted state - -Config value: `stateaware` - -**DEPRECATED:** The `stateaware` policy is **deprecated** in YuniKorn 1.5.0 and -will be **removed** in YuniKorn 1.6.0. To preserve backwards compatibility, -`stateaware` will become an alias for `fifo` in YuniKorn 1.6.0 and later. -Users are encouraged to migrate to `fifo` and utilize either gang scheduling or -`maxapplications` to limit concurrency instead. - -This sorting policy requires an understanding of the application states. -Applications states are described in the [application states](developer_guide/scheduler_object_states.md#application-state) documentation. - -Before sorting applications the following filters are applied to all applications in the queue: -The first filter is based on the application state. -The following applications pass through the filter and generate the first intermediate list: -* all applications in the state _running_ -* _one_ (1) application in the _starting_ state -* if there are _no_ applications in the _starting_ state _one_ (1) application in the _accepted_ state is added - -The second filter takes the result of the first filter as an input. -The preliminary list is filtered again: all applications _without_ a pending request are removed. - -After filtering based on status and pending requests the applications that remain are sorted. -The final list is thus filtered twice with the remaining applications sorted on create time. - -To recap the _staring_ and _accepted_ state interactions: -The application in the _accepted_ state is only added if there is no application in the _starting_ state. -The application in the _starting_ state does not have to have pending requests. -Any application in the _starting_ state will prevent _accepted_ applications from being added to the filtered list. - -For further details see the [Example run](design/state_aware_scheduling.md#example-run) in the design document. - -The result is that already running applications that request resources will get resources first. -A drip feed of one new applications is added to the list of running applications to be allocated after all running applications. - ## Node sorting The node sorting policy is set for a partition via the config. Each partition can use a different policy. diff --git a/sidebars.js b/sidebars.js index b5e61695d1..31d090cb08 100644 --- a/sidebars.js +++ b/sidebars.js @@ -93,7 +93,6 @@ module.exports = { 'design/generic_resource', 'design/priority_scheduling', 'design/resilience', - 'design/state_aware_scheduling', 'design/config_v2', 'design/scheduler_configuration', ] @@ -106,6 +105,7 @@ module.exports = { 'archived_design/namespace_resource_quota', 'archived_design/predicates', 'archived_design/scheduler_core_design', + 'archived_design/state_aware_scheduling', 'archived_design/cross_queue_preemption', 'archived_design/pluggable_app_management', ] --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org For additional commands, e-mail: issues-h...@yunikorn.apache.org