You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by ma...@apache.org on 2026/02/04 07:01:46 UTC
(yunikorn-site) branch master updated: [YUNIKORN-3169] Update website for 1.8.0 (#543)
This is an automated email from the ASF dual-hosted git repository.
mani 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 37e4dc7c0d [YUNIKORN-3169] Update website for 1.8.0 (#543)
37e4dc7c0d is described below
commit 37e4dc7c0d5a2547accb931ce75772f5438da1aa
Author: Wilfred Spiegelenburg <wi...@apache.org>
AuthorDate: Wed Feb 4 12:31:22 2026 +0530
[YUNIKORN-3169] Update website for 1.8.0 (#543)
Removed older release documentation
Updated roadmap
Fixed DOAP file for 1.6.0 releases and later
Fixed K8s support version for 1.7.0
typos in release announcement
Documentation part of moving the statedump and stack calls to the /debug
endpoint. Fixed layout issues in scheduler document.
Moved the metrics, config and validate-config to the correct document
based on the route details.
consistency branch update
Documentation part of moving the statedump and stack calls to the /debug
endpoint. Fixed layout issues in scheduler document.
Moved the metrics, config and validate-config to the correct document
based on the route details.
line length fixes
Closes: #543
Signed-off-by: Manikandan R <ma...@gmail.com>
---
doap_YuniKorn.rdf | 15 +
docs/get_started/version.md | 3 +
docusaurus.config.js | 2 +-
src/pages/community/download.md | 12 +-
src/pages/community/events.md | 43 +-
src/pages/community/release_procedure.md | 70 +-
src/pages/community/roadmap.md | 36 +-
src/pages/release-announce/1.8.0.md | 123 ++
versioned_docs/version-1.5.0/api/cluster.md | 79 -
versioned_docs/version-1.5.0/api/scheduler.md | 2152 -------------------
versioned_docs/version-1.5.0/api/system.md | 225 --
.../version-1.5.0/archived_design/k8shim.md | 74 -
.../version-1.5.0/assets/application-state.png | Bin 136449 -> 0 bytes
.../version-1.5.0/assets/dashboard_secret.png | Bin 31815 -> 0 bytes
.../assets/dashboard_token_select.png | Bin 47533 -> 0 bytes
.../version-1.5.0/assets/grafana_dashboard.png | Bin 215232 -> 0 bytes
.../assets/k8shim-application-state.png | Bin 224871 -> 0 bytes
.../version-1.5.0/assets/k8shim-node-state.png | Bin 52316 -> 0 bytes
.../version-1.5.0/assets/priority-tree.png | Bin 142135 -> 0 bytes
.../version-1.5.0/assets/queue-resource-quotas.png | Bin 283689 -> 0 bytes
.../version-1.5.0/design/cache_removal.md | 456 ----
versioned_docs/version-1.5.0/design/config_v2.md | 346 ---
.../design/historical_usage_tracking.md | 762 -------
versioned_docs/version-1.5.0/design/preemption.md | 581 ------
.../design/scheduler_configuration.md | 246 ---
.../version-1.5.0/design/user_group_manager.md | 410 ----
.../version-1.5.0/developer_guide/build.md | 244 ---
.../version-1.5.0/developer_guide/dependencies.md | 124 --
.../version-1.5.0/developer_guide/deployment.md | 148 --
.../version-1.5.0/developer_guide/env_setup.md | 299 ---
.../developer_guide/scheduler_object_states.md | 123 --
.../version-1.5.0/get_started/core_features.md | 95 -
.../version-1.5.0/get_started/get_started.md | 83 -
.../version-1.5.0/get_started/version.md | 58 -
versioned_docs/version-1.5.0/metrics/queue.md | 110 -
.../performance/performance_tutorial.md | 522 -----
versioned_docs/version-1.5.0/user_guide/acls.md | 119 --
.../version-1.5.0/user_guide/deployment_modes.md | 51 -
.../version-1.5.0/user_guide/gang_scheduling.md | 297 ---
.../labels_and_annotations_in_yunikorn.md | 55 -
.../version-1.5.0/user_guide/placement_rules.md | 355 ----
.../version-1.5.0/user_guide/preemption.md | 231 ---
.../version-1.5.0/user_guide/prometheus.md | 169 --
.../version-1.5.0/user_guide/queue_config.md | 464 -----
.../user_guide/resource_quota_mgmt.md | 348 ----
.../version-1.5.0/user_guide/service_config.md | 1088 ----------
.../version-1.5.0/user_guide/sorting_policies.md | 199 --
.../version-1.5.0/user_guide/troubleshooting.md | 227 --
.../version-1.5.0/user_guide/use_case.md | 483 -----
.../user_guide/usergroup_resolution.md | 120 --
.../user_guide/workloads/run_spark.md | 166 --
.../user_guide/workloads/workload_overview.md | 60 -
versioned_docs/version-1.5.1/api/cluster.md | 79 -
versioned_docs/version-1.5.1/api/scheduler.md | 2140 -------------------
versioned_docs/version-1.5.1/api/system.md | 225 --
.../archived_design/cross_queue_preemption.md | 126 --
.../version-1.5.1/archived_design/k8shim.md | 74 -
.../archived_design/namespace_resource_quota.md | 183 --
.../archived_design/pluggable_app_management.md | 75 -
.../version-1.5.1/archived_design/predicates.md | 80 -
.../archived_design/scheduler_core_design.md | 401 ----
.../archived_design/state_aware_scheduling.md | 112 -
.../version-1.5.1/assets/RunningSparkOnK8s.png | Bin 25878 -> 0 bytes
.../version-1.5.1/assets/allocation_4k.png | Bin 68868 -> 0 bytes
.../version-1.5.1/assets/architecture.png | Bin 188534 -> 0 bytes
.../version-1.5.1/assets/cpu_profile.jpg | Bin 259919 -> 0 bytes
.../version-1.5.1/assets/dashboard_secret.png | Bin 31815 -> 0 bytes
.../assets/dashboard_token_select.png | Bin 47533 -> 0 bytes
.../assets/docker-dektop-minikube.png | Bin 249095 -> 0 bytes
.../version-1.5.1/assets/docker-desktop.png | Bin 247891 -> 0 bytes
.../version-1.5.1/assets/external_userinfo.png | Bin 112563 -> 0 bytes
.../version-1.5.1/assets/fifo-state-example.png | Bin 239302 -> 0 bytes
.../version-1.5.1/assets/gang_clean_up.png | Bin 169887 -> 0 bytes
.../version-1.5.1/assets/gang_generic_flow.png | Bin 222524 -> 0 bytes
.../version-1.5.1/assets/gang_scheduling_intro.png | Bin 43907 -> 0 bytes
.../version-1.5.1/assets/gang_timeout.png | Bin 179466 -> 0 bytes
.../version-1.5.1/assets/gang_total_ask.png | Bin 22557 -> 0 bytes
.../version-1.5.1/assets/goland_debug.jpg | Bin 198845 -> 0 bytes
.../version-1.5.1/assets/goland_debug.png | Bin 290778 -> 0 bytes
.../version-1.5.1/assets/grafana_dashboard.png | Bin 215232 -> 0 bytes
.../version-1.5.1/assets/grafana_login_page.png | Bin 1785895 -> 0 bytes
.../version-1.5.1/assets/import_dashboard_01.png | Bin 701141 -> 0 bytes
.../version-1.5.1/assets/import_dashboard_02.png | Bin 283108 -> 0 bytes
.../assets/k8shim-application-state.png | Bin 224871 -> 0 bytes
.../version-1.5.1/assets/k8shim-task-state.png | Bin 179093 -> 0 bytes
.../version-1.5.1/assets/kwok-affinity.png | Bin 10716 -> 0 bytes
.../version-1.5.1/assets/kwok-priorityclass.png | Bin 19425 -> 0 bytes
.../version-1.5.1/assets/kwok-throughput-01.png | Bin 19471 -> 0 bytes
.../version-1.5.1/assets/kwok-throughput-02.png | Bin 19317 -> 0 bytes
.../version-1.5.1/assets/kwok-throughput-03.png | Bin 18247 -> 0 bytes
.../version-1.5.1/assets/kwok-toleration-taint.png | Bin 10541 -> 0 bytes
.../version-1.5.1/assets/namespace-mapping.png | Bin 327547 -> 0 bytes
.../version-1.5.1/assets/node-bin-packing.png | Bin 232909 -> 0 bytes
versioned_docs/version-1.5.1/assets/node-fair.png | Bin 462310 -> 0 bytes
.../version-1.5.1/assets/node_fairness_conf.png | Bin 12287 -> 0 bytes
.../version-1.5.1/assets/object-state.png | Bin 39732 -> 0 bytes
.../version-1.5.1/assets/perf-tutorial-build.png | Bin 53518 -> 0 bytes
.../assets/perf-tutorial-resultDiagrams.png | Bin 251263 -> 0 bytes
.../assets/perf-tutorial-resultLog.png | Bin 204787 -> 0 bytes
.../version-1.5.1/assets/perf_e2e_test.png | Bin 3957 -> 0 bytes
.../version-1.5.1/assets/perf_e2e_test_conf.png | Bin 25200 -> 0 bytes
.../version-1.5.1/assets/perf_node_fairness.png | Bin 26614 -> 0 bytes
.../version-1.5.1/assets/perf_throughput.png | Bin 13024 -> 0 bytes
.../version-1.5.1/assets/pluggable-app-mgmt.jpg | Bin 79170 -> 0 bytes
.../version-1.5.1/assets/predicateComaparation.png | Bin 182417 -> 0 bytes
.../version-1.5.1/assets/predicate_4k.png | Bin 86281 -> 0 bytes
.../version-1.5.1/assets/preemption_fence.png | Bin 105855 -> 0 bytes
.../assets/preemption_fence_case1.png | Bin 12023 -> 0 bytes
.../assets/preemption_fence_case2.png | Bin 19244 -> 0 bytes
.../assets/preemption_fence_hierarchy_case.png | Bin 63151 -> 0 bytes
.../assets/preemption_normal_case.png | Bin 18914 -> 0 bytes
.../assets/preemption_priority_queue_case.png | Bin 23392 -> 0 bytes
.../assets/preemption_priorityclass_case.png | Bin 25626 -> 0 bytes
.../version-1.5.1/assets/priority-flows.png | Bin 233513 -> 0 bytes
.../version-1.5.1/assets/priority-tree.png | Bin 142135 -> 0 bytes
.../version-1.5.1/assets/prometheus-cmd.png | Bin 542991 -> 0 bytes
.../version-1.5.1/assets/prometheus-web-ui.png | Bin 324110 -> 0 bytes
versioned_docs/version-1.5.1/assets/prometheus.png | Bin 88021 -> 0 bytes
.../version-1.5.1/assets/queue-fairness.png | Bin 173299 -> 0 bytes
.../version-1.5.1/assets/queue-resource-quotas.png | Bin 283689 -> 0 bytes
.../version-1.5.1/assets/quota_check.png | Bin 235186 -> 0 bytes
.../assets/resilience-node-recovery.jpg | Bin 319477 -> 0 bytes
.../version-1.5.1/assets/resilience-workflow.jpg | Bin 441551 -> 0 bytes
.../assets/scheduling_no_predicate_4k.png | Bin 96404 -> 0 bytes
.../assets/scheduling_with_predicate_4k_.png | Bin 107557 -> 0 bytes
.../version-1.5.1/assets/simple_preemptor.png | Bin 81655 -> 0 bytes
.../version-1.5.1/assets/sparkResult.png | Bin 38170 -> 0 bytes
.../version-1.5.1/assets/tf-job-gpu-on-logs.png | Bin 221691 -> 0 bytes
.../version-1.5.1/assets/tf-job-gpu-on-ui.png | Bin 101211 -> 0 bytes
.../version-1.5.1/assets/tf-job-on-ui.png | Bin 327800 -> 0 bytes
versioned_docs/version-1.5.1/assets/throughput.png | Bin 252615 -> 0 bytes
.../version-1.5.1/assets/throughput_3types.png | Bin 173025 -> 0 bytes
.../version-1.5.1/assets/throughput_conf.png | Bin 26837 -> 0 bytes
.../version-1.5.1/assets/translationBuilding.png | Bin 152552 -> 0 bytes
.../version-1.5.1/assets/translationDemo.png | Bin 4243960 -> 0 bytes
versioned_docs/version-1.5.1/assets/ug_lookup.png | Bin 106036 -> 0 bytes
.../version-1.5.1/assets/yk-ui-screenshots.gif | Bin 1126148 -> 0 bytes
.../assets/yunikorn-gpu-time-slicing.png | Bin 40653 -> 0 bytes
.../version-1.5.1/assets/yunirkonVSdefault.png | Bin 156100 -> 0 bytes
.../version-1.5.1/design/architecture.md | 62 -
.../version-1.5.1/design/cache_removal.md | 456 ----
versioned_docs/version-1.5.1/design/config_v2.md | 346 ---
.../version-1.5.1/design/gang_scheduling.md | 605 ------
.../version-1.5.1/design/generic_resource.md | 69 -
.../design/interface_message_simplification.md | 309 ---
versioned_docs/version-1.5.1/design/preemption.md | 581 ------
.../version-1.5.1/design/priority_scheduling.md | 408 ----
versioned_docs/version-1.5.1/design/resilience.md | 144 --
.../design/scheduler_configuration.md | 246 ---
.../version-1.5.1/design/scheduler_plugin.md | 112 -
.../version-1.5.1/design/simple_preemptor.md | 114 -
.../version-1.5.1/design/user_group_enforcement.md | 478 -----
.../version-1.5.1/design/user_group_handling.md | 290 ---
.../version-1.5.1/developer_guide/build.md | 244 ---
.../version-1.5.1/developer_guide/dependencies.md | 124 --
.../version-1.5.1/developer_guide/deployment.md | 145 --
.../version-1.5.1/developer_guide/e2e_test.md | 97 -
.../version-1.5.1/developer_guide/env_setup.md | 299 ---
.../developer_guide/openshift_development.md | 189 --
.../version-1.5.1/get_started/get_started.md | 83 -
.../version-1.5.1/get_started/version.md | 58 -
versioned_docs/version-1.5.1/metrics/queue.md | 110 -
versioned_docs/version-1.5.1/metrics/runtime.md | 39 -
versioned_docs/version-1.5.1/metrics/scheduler.mdx | 314 ---
.../evaluate_perf_function_with_kubemark.md | 120 --
.../evaluate_perf_function_with_kwok.md | 173 --
.../version-1.5.1/performance/metrics.md | 105 -
.../performance/performance_tutorial.md | 522 -----
.../version-1.5.1/performance/profiling.md | 122 --
versioned_docs/version-1.5.1/user_guide/acls.md | 119 --
.../version-1.5.1/user_guide/gang_scheduling.md | 297 ---
.../labels_and_annotations_in_yunikorn.md | 52 -
.../version-1.5.1/user_guide/placement_rules.md | 355 ----
.../version-1.5.1/user_guide/preemption.md | 231 ---
.../version-1.5.1/user_guide/priorities.md | 220 --
.../version-1.5.1/user_guide/prometheus.md | 169 --
.../version-1.5.1/user_guide/queue_config.md | 464 -----
.../user_guide/resource_quota_mgmt.md | 348 ----
.../version-1.5.1/user_guide/service_config.md | 1131 ----------
.../version-1.5.1/user_guide/sorting_policies.md | 162 --
.../version-1.5.1/user_guide/troubleshooting.md | 227 --
.../version-1.5.1/user_guide/use_case.md | 483 -----
.../user_guide/usergroup_resolution.md | 120 --
.../user_guide/workloads/run_flink.md | 66 -
.../version-1.5.1/user_guide/workloads/run_mpi.md | 112 -
.../user_guide/workloads/run_nvidia.md | 353 ----
.../user_guide/workloads/run_spark.md | 166 --
.../user_guide/workloads/run_tensorflow.md | 228 --
.../user_guide/workloads/workload_overview.md | 60 -
versioned_docs/version-1.6.0/api/cluster.md | 69 -
versioned_docs/version-1.6.0/api/scheduler.md | 2192 --------------------
versioned_docs/version-1.6.0/api/system.md | 226 --
.../archived_design/cross_queue_preemption.md | 126 --
.../archived_design/namespace_resource_quota.md | 183 --
.../archived_design/pluggable_app_management.md | 75 -
.../version-1.6.0/archived_design/predicates.md | 80 -
.../archived_design/scheduler_core_design.md | 401 ----
.../archived_design/state_aware_scheduling.md | 112 -
.../version-1.6.0/assets/RunningSparkOnK8s.png | Bin 25878 -> 0 bytes
.../version-1.6.0/assets/allocation_4k.png | Bin 68868 -> 0 bytes
.../version-1.6.0/assets/application-state.png | Bin 105253 -> 0 bytes
.../version-1.6.0/assets/architecture.png | Bin 188534 -> 0 bytes
.../version-1.6.0/assets/cpu_profile.jpg | Bin 259919 -> 0 bytes
.../assets/docker-dektop-minikube.png | Bin 249095 -> 0 bytes
.../version-1.6.0/assets/docker-desktop.png | Bin 247891 -> 0 bytes
.../version-1.6.0/assets/external_userinfo.png | Bin 112563 -> 0 bytes
.../version-1.6.0/assets/fifo-state-example.png | Bin 239302 -> 0 bytes
.../version-1.6.0/assets/gang_clean_up.png | Bin 169887 -> 0 bytes
.../version-1.6.0/assets/gang_generic_flow.png | Bin 222524 -> 0 bytes
.../version-1.6.0/assets/gang_scheduling_intro.png | Bin 43907 -> 0 bytes
.../version-1.6.0/assets/gang_timeout.png | Bin 179466 -> 0 bytes
.../version-1.6.0/assets/gang_total_ask.png | Bin 22557 -> 0 bytes
.../version-1.6.0/assets/goland_debug.jpg | Bin 198845 -> 0 bytes
.../version-1.6.0/assets/goland_debug.png | Bin 290778 -> 0 bytes
.../version-1.6.0/assets/grafana_dashboard.png | Bin 215232 -> 0 bytes
.../version-1.6.0/assets/grafana_login_page.png | Bin 1785895 -> 0 bytes
.../version-1.6.0/assets/import_dashboard_01.png | Bin 701141 -> 0 bytes
.../version-1.6.0/assets/import_dashboard_02.png | Bin 283108 -> 0 bytes
.../version-1.6.0/assets/k8shim-task-state.png | Bin 179093 -> 0 bytes
.../version-1.6.0/assets/kwok-affinity.png | Bin 10716 -> 0 bytes
.../version-1.6.0/assets/kwok-priorityclass.png | Bin 19425 -> 0 bytes
.../version-1.6.0/assets/kwok-throughput-01.png | Bin 19471 -> 0 bytes
.../version-1.6.0/assets/kwok-throughput-02.png | Bin 19317 -> 0 bytes
.../version-1.6.0/assets/kwok-throughput-03.png | Bin 18247 -> 0 bytes
.../version-1.6.0/assets/kwok-toleration-taint.png | Bin 10541 -> 0 bytes
.../version-1.6.0/assets/namespace-mapping.png | Bin 327547 -> 0 bytes
.../version-1.6.0/assets/node-bin-packing.png | Bin 232909 -> 0 bytes
versioned_docs/version-1.6.0/assets/node-fair.png | Bin 462310 -> 0 bytes
.../version-1.6.0/assets/node_fairness_conf.png | Bin 12287 -> 0 bytes
.../version-1.6.0/assets/object-state.png | Bin 39732 -> 0 bytes
.../version-1.6.0/assets/perf-tutorial-build.png | Bin 53518 -> 0 bytes
.../assets/perf-tutorial-resultDiagrams.png | Bin 251263 -> 0 bytes
.../assets/perf-tutorial-resultLog.png | Bin 204787 -> 0 bytes
.../version-1.6.0/assets/perf_e2e_test.png | Bin 3957 -> 0 bytes
.../version-1.6.0/assets/perf_e2e_test_conf.png | Bin 25200 -> 0 bytes
.../version-1.6.0/assets/perf_node_fairness.png | Bin 26614 -> 0 bytes
.../version-1.6.0/assets/perf_throughput.png | Bin 13024 -> 0 bytes
.../version-1.6.0/assets/pluggable-app-mgmt.jpg | Bin 79170 -> 0 bytes
.../version-1.6.0/assets/predicateComaparation.png | Bin 182417 -> 0 bytes
.../version-1.6.0/assets/predicate_4k.png | Bin 86281 -> 0 bytes
.../version-1.6.0/assets/preemption_fence.png | Bin 105855 -> 0 bytes
.../assets/preemption_fence_case1.png | Bin 12023 -> 0 bytes
.../assets/preemption_fence_case2.png | Bin 19244 -> 0 bytes
.../assets/preemption_fence_hierarchy_case.png | Bin 63151 -> 0 bytes
.../assets/preemption_normal_case.png | Bin 18914 -> 0 bytes
.../assets/preemption_priority_queue_case.png | Bin 23392 -> 0 bytes
.../assets/preemption_priorityclass_case.png | Bin 25626 -> 0 bytes
.../version-1.6.0/assets/priority-flows.png | Bin 233513 -> 0 bytes
.../version-1.6.0/assets/priority-tree.png | Bin 142135 -> 0 bytes
.../version-1.6.0/assets/prometheus-cmd.png | Bin 542991 -> 0 bytes
.../version-1.6.0/assets/prometheus-web-ui.png | Bin 324110 -> 0 bytes
versioned_docs/version-1.6.0/assets/prometheus.png | Bin 88021 -> 0 bytes
.../version-1.6.0/assets/queue-fairness.png | Bin 173299 -> 0 bytes
.../version-1.6.0/assets/queue-resource-quotas.png | Bin 283689 -> 0 bytes
.../version-1.6.0/assets/quota_check.png | Bin 235186 -> 0 bytes
.../assets/resilience-node-recovery.jpg | Bin 319477 -> 0 bytes
.../version-1.6.0/assets/resilience-workflow.jpg | Bin 441551 -> 0 bytes
.../assets/scheduling_no_predicate_4k.png | Bin 96404 -> 0 bytes
.../assets/scheduling_with_predicate_4k_.png | Bin 107557 -> 0 bytes
.../version-1.6.0/assets/simple_preemptor.png | Bin 81655 -> 0 bytes
.../version-1.6.0/assets/sparkResult.png | Bin 38170 -> 0 bytes
.../version-1.6.0/assets/tf-job-gpu-on-logs.png | Bin 221691 -> 0 bytes
.../version-1.6.0/assets/tf-job-gpu-on-ui.png | Bin 101211 -> 0 bytes
.../version-1.6.0/assets/tf-job-on-ui.png | Bin 327800 -> 0 bytes
versioned_docs/version-1.6.0/assets/throughput.png | Bin 252615 -> 0 bytes
.../version-1.6.0/assets/throughput_3types.png | Bin 173025 -> 0 bytes
.../version-1.6.0/assets/throughput_conf.png | Bin 26837 -> 0 bytes
.../version-1.6.0/assets/translationBuilding.png | Bin 152552 -> 0 bytes
.../version-1.6.0/assets/translationDemo.png | Bin 4243960 -> 0 bytes
versioned_docs/version-1.6.0/assets/ug_lookup.png | Bin 106036 -> 0 bytes
.../version-1.6.0/assets/yk-ui-screenshots.gif | Bin 1126148 -> 0 bytes
.../assets/yunikorn-gpu-time-slicing.png | Bin 40653 -> 0 bytes
.../version-1.6.0/assets/yunirkonVSdefault.png | Bin 156100 -> 0 bytes
.../version-1.6.0/design/architecture.md | 62 -
versioned_docs/version-1.6.0/design/config_v2.md | 346 ---
.../version-1.6.0/design/gang_scheduling.md | 605 ------
.../version-1.6.0/design/generic_resource.md | 69 -
.../design/historical_usage_tracking.md | 759 -------
.../design/interface_message_simplification.md | 309 ---
.../version-1.6.0/design/priority_scheduling.md | 408 ----
versioned_docs/version-1.6.0/design/resilience.md | 144 --
.../design/scheduler_configuration.md | 246 ---
.../version-1.6.0/design/scheduler_plugin.md | 112 -
.../version-1.6.0/design/simple_preemptor.md | 114 -
.../version-1.6.0/design/user_group_enforcement.md | 478 -----
.../version-1.6.0/design/user_group_handling.md | 290 ---
.../version-1.6.0/design/user_group_manager.md | 410 ----
.../version-1.6.0/developer_guide/deployment.md | 145 --
.../version-1.6.0/developer_guide/env_setup.md | 287 ---
.../developer_guide/openshift_development.md | 189 --
.../developer_guide/scheduler_object_states.md | 113 -
.../version-1.6.0/get_started/core_features.md | 101 -
.../version-1.6.0/get_started/get_started.md | 88 -
.../version-1.6.0/get_started/version.md | 60 -
versioned_docs/version-1.6.0/metrics/queue.md | 110 -
versioned_docs/version-1.6.0/metrics/runtime.md | 39 -
versioned_docs/version-1.6.0/metrics/scheduler.mdx | 314 ---
.../evaluate_perf_function_with_kubemark.md | 120 --
.../evaluate_perf_function_with_kwok.md | 173 --
.../version-1.6.0/performance/metrics.md | 105 -
.../version-1.6.0/performance/profiling.md | 122 --
versioned_docs/version-1.6.0/user_guide/acls.md | 119 --
.../version-1.6.0/user_guide/deployment_modes.md | 69 -
.../version-1.6.0/user_guide/event_system.md | 147 --
.../version-1.6.0/user_guide/gang_scheduling.md | 296 ---
.../labels_and_annotations_in_yunikorn.md | 61 -
.../user_guide/observability/prometheus.md | 181 --
.../version-1.6.0/user_guide/placement_rules.md | 348 ----
.../version-1.6.0/user_guide/preemption.md | 282 ---
.../version-1.6.0/user_guide/priorities.md | 220 --
.../version-1.6.0/user_guide/queue_config.md | 491 -----
.../user_guide/resource_quota_mgmt.md | 348 ----
.../version-1.6.0/user_guide/service_config.md | 1166 -----------
.../version-1.6.0/user_guide/sorting_policies.md | 162 --
.../version-1.6.0/user_guide/troubleshooting.md | 234 ---
.../version-1.6.0/user_guide/use_case.md | 483 -----
.../user_guide/usergroup_resolution.md | 118 --
.../user_guide/workloads/kuberay/_ray_operator.mdx | 8 -
.../user_guide/workloads/run_flink.md | 66 -
.../version-1.6.0/user_guide/workloads/run_mpi.md | 112 -
.../user_guide/workloads/run_nvidia.md | 353 ----
.../user_guide/workloads/run_ray_cluster.md | 66 -
.../user_guide/workloads/run_spark.md | 180 --
.../user_guide/workloads/run_tensorflow.md | 228 --
versioned_docs/version-1.6.1/api/cluster.md | 69 -
versioned_docs/version-1.6.1/api/scheduler.md | 2192 --------------------
versioned_docs/version-1.6.1/api/system.md | 226 --
.../archived_design/cross_queue_preemption.md | 126 --
.../version-1.6.1/archived_design/k8shim.md | 74 -
.../archived_design/namespace_resource_quota.md | 183 --
.../archived_design/pluggable_app_management.md | 75 -
.../version-1.6.1/archived_design/predicates.md | 80 -
.../archived_design/scheduler_core_design.md | 401 ----
.../archived_design/state_aware_scheduling.md | 112 -
.../version-1.6.1/assets/RunningSparkOnK8s.png | Bin 25878 -> 0 bytes
.../version-1.6.1/assets/allocation_4k.png | Bin 68868 -> 0 bytes
.../version-1.6.1/assets/application-state.png | Bin 105253 -> 0 bytes
.../version-1.6.1/assets/architecture.png | Bin 188534 -> 0 bytes
.../version-1.6.1/assets/cpu_profile.jpg | Bin 259919 -> 0 bytes
.../version-1.6.1/assets/dashboard_bearertoken.png | Bin 36641 -> 0 bytes
.../assets/docker-dektop-minikube.png | Bin 249095 -> 0 bytes
.../version-1.6.1/assets/docker-desktop.png | Bin 247891 -> 0 bytes
.../version-1.6.1/assets/external_userinfo.png | Bin 112563 -> 0 bytes
.../version-1.6.1/assets/fifo-state-example.png | Bin 239302 -> 0 bytes
.../version-1.6.1/assets/gang_clean_up.png | Bin 169887 -> 0 bytes
.../version-1.6.1/assets/gang_generic_flow.png | Bin 222524 -> 0 bytes
.../version-1.6.1/assets/gang_scheduling_intro.png | Bin 43907 -> 0 bytes
.../version-1.6.1/assets/gang_timeout.png | Bin 179466 -> 0 bytes
.../version-1.6.1/assets/gang_total_ask.png | Bin 22557 -> 0 bytes
.../assets/github-ci-log-artifacts.png | Bin 134904 -> 0 bytes
.../version-1.6.1/assets/goland_debug.jpg | Bin 198845 -> 0 bytes
.../version-1.6.1/assets/goland_debug.png | Bin 290778 -> 0 bytes
versioned_docs/version-1.6.1/assets/grafana.png | Bin 147454 -> 0 bytes
.../version-1.6.1/assets/grafana_dashboard.png | Bin 215232 -> 0 bytes
.../version-1.6.1/assets/grafana_login_page.png | Bin 1785895 -> 0 bytes
.../assets/grafana_loki_setting_1.png | Bin 78243 -> 0 bytes
.../assets/grafana_loki_setting_2.png | Bin 63025 -> 0 bytes
.../version-1.6.1/assets/import_dashboard_01.png | Bin 701141 -> 0 bytes
.../version-1.6.1/assets/import_dashboard_02.png | Bin 283108 -> 0 bytes
.../assets/k8shim-application-state.png | Bin 203060 -> 0 bytes
.../version-1.6.1/assets/k8shim-task-state.png | Bin 179093 -> 0 bytes
.../version-1.6.1/assets/kwok-affinity.png | Bin 10716 -> 0 bytes
.../version-1.6.1/assets/kwok-priorityclass.png | Bin 19425 -> 0 bytes
.../version-1.6.1/assets/kwok-throughput-01.png | Bin 19471 -> 0 bytes
.../version-1.6.1/assets/kwok-throughput-02.png | Bin 19317 -> 0 bytes
.../version-1.6.1/assets/kwok-throughput-03.png | Bin 18247 -> 0 bytes
.../version-1.6.1/assets/kwok-toleration-taint.png | Bin 10541 -> 0 bytes
versioned_docs/version-1.6.1/assets/loki.png | Bin 135549 -> 0 bytes
versioned_docs/version-1.6.1/assets/loki_log_1.png | Bin 79625 -> 0 bytes
versioned_docs/version-1.6.1/assets/loki_log_2.png | Bin 211028 -> 0 bytes
.../version-1.6.1/assets/loki_track_tg.png | Bin 75934 -> 0 bytes
.../version-1.6.1/assets/namespace-mapping.png | Bin 327547 -> 0 bytes
.../version-1.6.1/assets/node-bin-packing.png | Bin 232909 -> 0 bytes
versioned_docs/version-1.6.1/assets/node-fair.png | Bin 462310 -> 0 bytes
.../version-1.6.1/assets/node_fairness_conf.png | Bin 12287 -> 0 bytes
.../version-1.6.1/assets/object-state.png | Bin 39732 -> 0 bytes
.../version-1.6.1/assets/perf-tutorial-build.png | Bin 53518 -> 0 bytes
.../assets/perf-tutorial-resultDiagrams.png | Bin 251263 -> 0 bytes
.../assets/perf-tutorial-resultLog.png | Bin 204787 -> 0 bytes
.../version-1.6.1/assets/perf_e2e_test.png | Bin 3957 -> 0 bytes
.../version-1.6.1/assets/perf_e2e_test_conf.png | Bin 25200 -> 0 bytes
.../version-1.6.1/assets/perf_node_fairness.png | Bin 26614 -> 0 bytes
.../version-1.6.1/assets/perf_throughput.png | Bin 13024 -> 0 bytes
.../version-1.6.1/assets/pluggable-app-mgmt.jpg | Bin 79170 -> 0 bytes
.../version-1.6.1/assets/predicateComaparation.png | Bin 182417 -> 0 bytes
.../version-1.6.1/assets/predicate_4k.png | Bin 86281 -> 0 bytes
.../version-1.6.1/assets/preemption_fence.png | Bin 105855 -> 0 bytes
.../assets/preemption_fence_case1.png | Bin 12023 -> 0 bytes
.../assets/preemption_fence_case2.png | Bin 19244 -> 0 bytes
.../assets/preemption_fence_hierarchy_case.png | Bin 63151 -> 0 bytes
.../assets/preemption_normal_case.png | Bin 18914 -> 0 bytes
.../assets/preemption_priority_queue_case.png | Bin 23392 -> 0 bytes
.../assets/preemption_priorityclass_case.png | Bin 25626 -> 0 bytes
.../assets/preemption_quota_redistribution.png | Bin 204788 -> 0 bytes
.../version-1.6.1/assets/preemption_storm.png | Bin 238038 -> 0 bytes
.../version-1.6.1/assets/priority-flows.png | Bin 233513 -> 0 bytes
.../version-1.6.1/assets/priority-tree.png | Bin 142135 -> 0 bytes
.../version-1.6.1/assets/prometheus-cmd.png | Bin 542991 -> 0 bytes
.../assets/prometheus-web-ui-target-yunikorn.png | Bin 41973 -> 0 bytes
.../version-1.6.1/assets/prometheus-web-ui.png | Bin 324110 -> 0 bytes
versioned_docs/version-1.6.1/assets/prometheus.png | Bin 88021 -> 0 bytes
versioned_docs/version-1.6.1/assets/promtail.png | Bin 142055 -> 0 bytes
.../version-1.6.1/assets/queue-fairness.png | Bin 173299 -> 0 bytes
.../version-1.6.1/assets/queue-resource-quotas.png | Bin 283689 -> 0 bytes
.../version-1.6.1/assets/quota_check.png | Bin 235186 -> 0 bytes
.../version-1.6.1/assets/ray_cluster_cluster.png | Bin 169047 -> 0 bytes
.../version-1.6.1/assets/ray_cluster_on_ui.png | Bin 150116 -> 0 bytes
.../version-1.6.1/assets/ray_cluster_operator.png | Bin 153070 -> 0 bytes
.../assets/ray_cluster_ray_dashborad.png | Bin 68327 -> 0 bytes
.../version-1.6.1/assets/ray_job_job.png | Bin 170877 -> 0 bytes
.../version-1.6.1/assets/ray_job_on_ui.png | Bin 146317 -> 0 bytes
.../version-1.6.1/assets/ray_job_ray_dashboard.png | Bin 58353 -> 0 bytes
.../assets/resilience-node-recovery.jpg | Bin 319477 -> 0 bytes
.../version-1.6.1/assets/resilience-workflow.jpg | Bin 441551 -> 0 bytes
.../run-ray-service-kuberay-dashboard-ui.png | Bin 28524 -> 0 bytes
...run-ray-service-kuberay-service-api-testing.png | Bin 40405 -> 0 bytes
.../assets/run-ray-service-kuberay-service-pod.png | Bin 59960 -> 0 bytes
.../assets/run-ray-service-yunikorn-ui.png | Bin 167907 -> 0 bytes
.../assets/scheduling_no_predicate_4k.png | Bin 96404 -> 0 bytes
.../assets/scheduling_with_predicate_4k_.png | Bin 107557 -> 0 bytes
.../version-1.6.1/assets/simple_preemptor.png | Bin 81655 -> 0 bytes
.../version-1.6.1/assets/sparkResult.png | Bin 38170 -> 0 bytes
.../version-1.6.1/assets/tf-job-gpu-on-logs.png | Bin 221691 -> 0 bytes
.../version-1.6.1/assets/tf-job-gpu-on-ui.png | Bin 101211 -> 0 bytes
.../version-1.6.1/assets/tf-job-on-ui.png | Bin 327800 -> 0 bytes
versioned_docs/version-1.6.1/assets/throughput.png | Bin 252615 -> 0 bytes
.../version-1.6.1/assets/throughput_3types.png | Bin 173025 -> 0 bytes
.../version-1.6.1/assets/throughput_conf.png | Bin 26837 -> 0 bytes
.../version-1.6.1/assets/translationBuilding.png | Bin 152552 -> 0 bytes
.../version-1.6.1/assets/translationDemo.png | Bin 4243960 -> 0 bytes
versioned_docs/version-1.6.1/assets/ug_lookup.png | Bin 106036 -> 0 bytes
.../version-1.6.1/assets/yk-ui-screenshots.gif | Bin 1126148 -> 0 bytes
.../assets/yunikorn-gpu-time-slicing.png | Bin 40653 -> 0 bytes
.../version-1.6.1/assets/yunirkonVSdefault.png | Bin 156100 -> 0 bytes
.../version-1.6.1/design/architecture.md | 62 -
.../version-1.6.1/design/cache_removal.md | 456 ----
versioned_docs/version-1.6.1/design/config_v2.md | 346 ---
.../version-1.6.1/design/gang_scheduling.md | 605 ------
.../version-1.6.1/design/generic_resource.md | 69 -
.../design/historical_usage_tracking.md | 759 -------
.../design/interface_message_simplification.md | 309 ---
versioned_docs/version-1.6.1/design/preemption.md | 581 ------
.../version-1.6.1/design/priority_scheduling.md | 408 ----
versioned_docs/version-1.6.1/design/resilience.md | 144 --
.../design/scheduler_configuration.md | 246 ---
.../version-1.6.1/design/scheduler_plugin.md | 112 -
.../version-1.6.1/design/simple_preemptor.md | 114 -
.../version-1.6.1/design/user_group_enforcement.md | 478 -----
.../version-1.6.1/design/user_group_handling.md | 290 ---
.../version-1.6.1/design/user_group_manager.md | 410 ----
.../version-1.6.1/developer_guide/build.md | 249 ---
.../version-1.6.1/developer_guide/dependencies.md | 124 --
.../version-1.6.1/developer_guide/deployment.md | 145 --
.../version-1.6.1/developer_guide/e2e_test.md | 129 --
.../version-1.6.1/developer_guide/env_setup.md | 287 ---
.../developer_guide/openshift_development.md | 189 --
.../developer_guide/scheduler_object_states.md | 113 -
.../version-1.6.1/get_started/core_features.md | 101 -
.../version-1.6.1/get_started/get_started.md | 88 -
versioned_docs/version-1.6.1/metrics/queue.md | 110 -
versioned_docs/version-1.6.1/metrics/runtime.md | 39 -
versioned_docs/version-1.6.1/metrics/scheduler.mdx | 314 ---
.../evaluate_perf_function_with_kubemark.md | 120 --
.../evaluate_perf_function_with_kwok.md | 173 --
.../version-1.6.1/performance/metrics.md | 105 -
.../performance/performance_tutorial.md | 522 -----
.../version-1.6.1/performance/profiling.md | 122 --
versioned_docs/version-1.6.1/user_guide/acls.md | 119 --
.../version-1.6.1/user_guide/deployment_modes.md | 69 -
.../version-1.6.1/user_guide/event_system.md | 147 --
.../version-1.6.1/user_guide/gang_scheduling.md | 296 ---
.../labels_and_annotations_in_yunikorn.md | 61 -
.../version-1.6.1/user_guide/observability/loki.md | 169 --
.../user_guide/observability/prometheus.md | 181 --
.../version-1.6.1/user_guide/placement_rules.md | 348 ----
.../version-1.6.1/user_guide/preemption.md | 282 ---
.../version-1.6.1/user_guide/priorities.md | 220 --
.../version-1.6.1/user_guide/queue_config.md | 491 -----
.../user_guide/resource_quota_mgmt.md | 348 ----
.../version-1.6.1/user_guide/service_config.md | 1206 -----------
.../version-1.6.1/user_guide/sorting_policies.md | 162 --
.../version-1.6.1/user_guide/troubleshooting.md | 234 ---
.../version-1.6.1/user_guide/use_case.md | 483 -----
.../user_guide/usergroup_resolution.md | 118 --
.../workloads/kuberay/_ray_crd_yunikorn_config.mdx | 11 -
.../user_guide/workloads/kuberay/_ray_operator.mdx | 8 -
.../user_guide/workloads/run_flink.md | 66 -
.../version-1.6.1/user_guide/workloads/run_mpi.md | 112 -
.../user_guide/workloads/run_nvidia.md | 353 ----
.../user_guide/workloads/run_ray_cluster.md | 66 -
.../user_guide/workloads/run_ray_job.md | 57 -
.../user_guide/workloads/run_ray_service.md | 71 -
.../user_guide/workloads/run_spark.md | 180 --
.../user_guide/workloads/run_tensorflow.md | 228 --
.../workloads/utils/_yunikorn_configmap_patch.mdx | 5 -
.../user_guide/workloads/workload_overview.md | 63 -
.../archived_design/cross_queue_preemption.md | 126 --
.../version-1.6.2/archived_design/k8shim.md | 74 -
.../archived_design/namespace_resource_quota.md | 183 --
.../archived_design/pluggable_app_management.md | 75 -
.../version-1.6.2/archived_design/predicates.md | 80 -
.../archived_design/scheduler_core_design.md | 401 ----
.../archived_design/state_aware_scheduling.md | 112 -
.../version-1.6.2/assets/RunningSparkOnK8s.png | Bin 25878 -> 0 bytes
.../version-1.6.2/assets/allocation_4k.png | Bin 68868 -> 0 bytes
.../version-1.6.2/assets/application-state.png | Bin 105253 -> 0 bytes
.../version-1.6.2/assets/architecture.png | Bin 188534 -> 0 bytes
.../version-1.6.2/assets/cpu_profile.jpg | Bin 259919 -> 0 bytes
.../version-1.6.2/assets/dashboard_bearertoken.png | Bin 36641 -> 0 bytes
.../assets/docker-dektop-minikube.png | Bin 249095 -> 0 bytes
.../version-1.6.2/assets/docker-desktop.png | Bin 247891 -> 0 bytes
.../version-1.6.2/assets/external_userinfo.png | Bin 112563 -> 0 bytes
.../version-1.6.2/assets/fifo-state-example.png | Bin 239302 -> 0 bytes
.../version-1.6.2/assets/gang_clean_up.png | Bin 169887 -> 0 bytes
.../version-1.6.2/assets/gang_generic_flow.png | Bin 222524 -> 0 bytes
.../version-1.6.2/assets/gang_scheduling_intro.png | Bin 43907 -> 0 bytes
.../version-1.6.2/assets/gang_timeout.png | Bin 179466 -> 0 bytes
.../version-1.6.2/assets/gang_total_ask.png | Bin 22557 -> 0 bytes
.../assets/github-ci-log-artifacts.png | Bin 134904 -> 0 bytes
.../version-1.6.2/assets/goland_debug.jpg | Bin 198845 -> 0 bytes
.../version-1.6.2/assets/goland_debug.png | Bin 290778 -> 0 bytes
versioned_docs/version-1.6.2/assets/grafana.png | Bin 147454 -> 0 bytes
.../version-1.6.2/assets/grafana_login_page.png | Bin 1785895 -> 0 bytes
.../assets/grafana_loki_setting_1.png | Bin 78243 -> 0 bytes
.../assets/grafana_loki_setting_2.png | Bin 63025 -> 0 bytes
.../version-1.6.2/assets/import_dashboard_01.png | Bin 701141 -> 0 bytes
.../version-1.6.2/assets/import_dashboard_02.png | Bin 283108 -> 0 bytes
.../assets/k8shim-application-state.png | Bin 203060 -> 0 bytes
.../version-1.6.2/assets/k8shim-task-state.png | Bin 179093 -> 0 bytes
.../version-1.6.2/assets/kwok-affinity.png | Bin 10716 -> 0 bytes
.../version-1.6.2/assets/kwok-priorityclass.png | Bin 19425 -> 0 bytes
.../version-1.6.2/assets/kwok-throughput-01.png | Bin 19471 -> 0 bytes
.../version-1.6.2/assets/kwok-throughput-02.png | Bin 19317 -> 0 bytes
.../version-1.6.2/assets/kwok-throughput-03.png | Bin 18247 -> 0 bytes
.../version-1.6.2/assets/kwok-toleration-taint.png | Bin 10541 -> 0 bytes
versioned_docs/version-1.6.2/assets/loki.png | Bin 135549 -> 0 bytes
versioned_docs/version-1.6.2/assets/loki_log_1.png | Bin 79625 -> 0 bytes
versioned_docs/version-1.6.2/assets/loki_log_2.png | Bin 211028 -> 0 bytes
.../version-1.6.2/assets/loki_track_tg.png | Bin 75934 -> 0 bytes
.../version-1.6.2/assets/namespace-mapping.png | Bin 327547 -> 0 bytes
.../version-1.6.2/assets/node-bin-packing.png | Bin 232909 -> 0 bytes
versioned_docs/version-1.6.2/assets/node-fair.png | Bin 462310 -> 0 bytes
.../version-1.6.2/assets/node_fairness_conf.png | Bin 12287 -> 0 bytes
.../version-1.6.2/assets/object-state.png | Bin 39732 -> 0 bytes
.../version-1.6.2/assets/perf-tutorial-build.png | Bin 53518 -> 0 bytes
.../assets/perf-tutorial-resultDiagrams.png | Bin 251263 -> 0 bytes
.../assets/perf-tutorial-resultLog.png | Bin 204787 -> 0 bytes
.../version-1.6.2/assets/perf_e2e_test.png | Bin 3957 -> 0 bytes
.../version-1.6.2/assets/perf_e2e_test_conf.png | Bin 25200 -> 0 bytes
.../version-1.6.2/assets/perf_node_fairness.png | Bin 26614 -> 0 bytes
.../version-1.6.2/assets/perf_throughput.png | Bin 13024 -> 0 bytes
.../version-1.6.2/assets/pluggable-app-mgmt.jpg | Bin 79170 -> 0 bytes
.../version-1.6.2/assets/predicateComaparation.png | Bin 182417 -> 0 bytes
.../version-1.6.2/assets/predicate_4k.png | Bin 86281 -> 0 bytes
.../version-1.6.2/assets/preemption_fence.png | Bin 105855 -> 0 bytes
.../assets/preemption_fence_case1.png | Bin 12023 -> 0 bytes
.../assets/preemption_fence_case2.png | Bin 19244 -> 0 bytes
.../assets/preemption_fence_hierarchy_case.png | Bin 63151 -> 0 bytes
.../assets/preemption_normal_case.png | Bin 18914 -> 0 bytes
.../assets/preemption_priority_queue_case.png | Bin 23392 -> 0 bytes
.../assets/preemption_priorityclass_case.png | Bin 25626 -> 0 bytes
.../assets/preemption_quota_redistribution.png | Bin 204788 -> 0 bytes
.../version-1.6.2/assets/preemption_storm.png | Bin 238038 -> 0 bytes
.../version-1.6.2/assets/priority-flows.png | Bin 233513 -> 0 bytes
.../version-1.6.2/assets/prometheus-cmd.png | Bin 542991 -> 0 bytes
.../assets/prometheus-web-ui-target-yunikorn.png | Bin 41973 -> 0 bytes
.../version-1.6.2/assets/prometheus-web-ui.png | Bin 324110 -> 0 bytes
versioned_docs/version-1.6.2/assets/prometheus.png | Bin 88021 -> 0 bytes
versioned_docs/version-1.6.2/assets/promtail.png | Bin 142055 -> 0 bytes
.../version-1.6.2/assets/queue-fairness.png | Bin 173299 -> 0 bytes
.../version-1.6.2/assets/quota_check.png | Bin 235186 -> 0 bytes
.../version-1.6.2/assets/ray_cluster_cluster.png | Bin 169047 -> 0 bytes
.../version-1.6.2/assets/ray_cluster_on_ui.png | Bin 150116 -> 0 bytes
.../version-1.6.2/assets/ray_cluster_operator.png | Bin 153070 -> 0 bytes
.../assets/ray_cluster_ray_dashborad.png | Bin 68327 -> 0 bytes
.../version-1.6.2/assets/ray_job_job.png | Bin 170877 -> 0 bytes
.../version-1.6.2/assets/ray_job_on_ui.png | Bin 146317 -> 0 bytes
.../version-1.6.2/assets/ray_job_ray_dashboard.png | Bin 58353 -> 0 bytes
.../assets/resilience-node-recovery.jpg | Bin 319477 -> 0 bytes
.../version-1.6.2/assets/resilience-workflow.jpg | Bin 441551 -> 0 bytes
.../run-ray-service-kuberay-dashboard-ui.png | Bin 28524 -> 0 bytes
...run-ray-service-kuberay-service-api-testing.png | Bin 40405 -> 0 bytes
.../assets/run-ray-service-kuberay-service-pod.png | Bin 59960 -> 0 bytes
.../assets/run-ray-service-yunikorn-ui.png | Bin 167907 -> 0 bytes
.../assets/scheduling_no_predicate_4k.png | Bin 96404 -> 0 bytes
.../assets/scheduling_with_predicate_4k_.png | Bin 107557 -> 0 bytes
.../version-1.6.2/assets/simple_preemptor.png | Bin 81655 -> 0 bytes
.../version-1.6.2/assets/sparkResult.png | Bin 38170 -> 0 bytes
.../version-1.6.2/assets/tf-job-gpu-on-logs.png | Bin 221691 -> 0 bytes
.../version-1.6.2/assets/tf-job-gpu-on-ui.png | Bin 101211 -> 0 bytes
.../version-1.6.2/assets/tf-job-on-ui.png | Bin 327800 -> 0 bytes
versioned_docs/version-1.6.2/assets/throughput.png | Bin 252615 -> 0 bytes
.../version-1.6.2/assets/throughput_3types.png | Bin 173025 -> 0 bytes
.../version-1.6.2/assets/throughput_conf.png | Bin 26837 -> 0 bytes
.../version-1.6.2/assets/translationBuilding.png | Bin 152552 -> 0 bytes
.../version-1.6.2/assets/translationDemo.png | Bin 4243960 -> 0 bytes
versioned_docs/version-1.6.2/assets/ug_lookup.png | Bin 106036 -> 0 bytes
.../version-1.6.2/assets/yk-ui-screenshots.gif | Bin 1126148 -> 0 bytes
.../assets/yunikorn-gpu-time-slicing.png | Bin 40653 -> 0 bytes
.../version-1.6.2/assets/yunirkonVSdefault.png | Bin 156100 -> 0 bytes
.../version-1.6.2/design/architecture.md | 62 -
.../version-1.6.2/design/cache_removal.md | 456 ----
.../version-1.6.2/design/gang_scheduling.md | 605 ------
.../version-1.6.2/design/generic_resource.md | 69 -
.../design/historical_usage_tracking.md | 759 -------
.../design/interface_message_simplification.md | 309 ---
versioned_docs/version-1.6.2/design/preemption.md | 581 ------
.../version-1.6.2/design/priority_scheduling.md | 408 ----
versioned_docs/version-1.6.2/design/resilience.md | 144 --
.../version-1.6.2/design/scheduler_plugin.md | 112 -
.../version-1.6.2/design/simple_preemptor.md | 114 -
.../version-1.6.2/design/user_group_enforcement.md | 478 -----
.../version-1.6.2/design/user_group_handling.md | 290 ---
.../version-1.6.2/design/user_group_manager.md | 410 ----
.../version-1.6.2/developer_guide/build.md | 249 ---
.../version-1.6.2/developer_guide/dependencies.md | 124 --
.../version-1.6.2/developer_guide/e2e_test.md | 129 --
.../developer_guide/openshift_development.md | 189 --
.../developer_guide/scheduler_object_states.md | 113 -
.../version-1.6.2/get_started/core_features.md | 101 -
.../version-1.6.2/get_started/version.md | 60 -
versioned_docs/version-1.6.2/metrics/queue.md | 110 -
versioned_docs/version-1.6.2/metrics/runtime.md | 39 -
versioned_docs/version-1.6.2/metrics/scheduler.mdx | 314 ---
.../evaluate_perf_function_with_kubemark.md | 120 --
.../evaluate_perf_function_with_kwok.md | 173 --
.../version-1.6.2/performance/metrics.md | 105 -
.../performance/performance_tutorial.md | 522 -----
.../version-1.6.2/performance/profiling.md | 122 --
.../version-1.6.2/user_guide/deployment_modes.md | 69 -
.../version-1.6.2/user_guide/event_system.md | 147 --
.../version-1.6.2/user_guide/observability/loki.md | 169 --
.../version-1.6.2/user_guide/priorities.md | 220 --
.../workloads/kuberay/_ray_crd_yunikorn_config.mdx | 11 -
.../user_guide/workloads/run_flink.md | 66 -
.../version-1.6.2/user_guide/workloads/run_mpi.md | 112 -
.../user_guide/workloads/run_nvidia.md | 353 ----
.../user_guide/workloads/run_ray_job.md | 57 -
.../user_guide/workloads/run_ray_service.md | 71 -
.../user_guide/workloads/run_tensorflow.md | 228 --
.../workloads/utils/_yunikorn_configmap_patch.mdx | 5 -
.../user_guide/workloads/workload_overview.md | 63 -
.../version-1.7.0/get_started/version.md | 1 +
.../api/cluster.md | 0
.../api/scheduler.md | 24 +-
.../{version-1.6.2 => version-1.8.0}/api/system.md | 6 +-
.../archived_design/cross_queue_preemption.md | 0
.../archived_design/k8shim.md | 4 +-
.../archived_design/namespace_resource_quota.md | 0
.../archived_design/pluggable_app_management.md | 0
.../archived_design/predicates.md | 0
.../archived_design/scheduler_core_design.md | 0
.../archived_design}/state_aware_scheduling.md | 0
.../assets/RunningSparkOnK8s.png | Bin
.../assets/allocation_4k.png | Bin
.../assets/application-state.png | Bin
.../assets/architecture.png | Bin
.../assets/cpu_profile.jpg | Bin
.../assets/dashboard_bearertoken.png | Bin
.../assets/docker-dektop-minikube.png | Bin
.../assets/docker-desktop.png | Bin
.../assets/external_userinfo.png | Bin
.../assets/fifo-state-example.png | Bin
.../assets/gang_clean_up.png | Bin
.../assets/gang_generic_flow.png | Bin
.../assets/gang_scheduling_intro.png | Bin
.../assets/gang_timeout.png | Bin
.../assets/gang_total_ask.png | Bin
.../assets/github-ci-log-artifacts.png | Bin
.../assets/goland_debug.jpg | Bin
.../assets/goland_debug.png | Bin
.../assets/grafana.png | Bin
.../assets/grafana_dashboard.png | Bin
.../assets/grafana_login_page.png | Bin
.../assets/grafana_loki_setting_1.png | Bin
.../assets/grafana_loki_setting_2.png | Bin
.../assets/import_dashboard_01.png | Bin
.../assets/import_dashboard_02.png | Bin
.../assets/k8shim-application-state.png | Bin
.../assets/k8shim-task-state.png | Bin
.../assets/kwok-affinity.png | Bin
.../assets/kwok-priorityclass.png | Bin
.../assets/kwok-throughput-01.png | Bin
.../assets/kwok-throughput-02.png | Bin
.../assets/kwok-throughput-03.png | Bin
.../assets/kwok-toleration-taint.png | Bin
.../assets/loki.png | Bin
.../assets/loki_log_1.png | Bin
.../assets/loki_log_2.png | Bin
.../assets/loki_track_tg.png | Bin
.../assets/namespace-mapping.png | Bin
.../assets/node-bin-packing.png | Bin
.../assets/node-fair.png | Bin
.../assets/node_fairness_conf.png | Bin
.../assets/object-state.png | Bin
.../assets/perf-tutorial-build.png | Bin
.../assets/perf-tutorial-resultDiagrams.png | Bin
.../assets/perf-tutorial-resultLog.png | Bin
.../assets/perf_e2e_test.png | Bin
.../assets/perf_e2e_test_conf.png | Bin
.../assets/perf_node_fairness.png | Bin
.../assets/perf_throughput.png | Bin
.../assets/pluggable-app-mgmt.jpg | Bin
.../assets/predicateComaparation.png | Bin
.../assets/predicate_4k.png | Bin
.../assets/preemption_fence.png | Bin
.../assets/preemption_fence_case1.png | Bin
.../assets/preemption_fence_case2.png | Bin
.../assets/preemption_fence_hierarchy_case.png | Bin
.../assets/preemption_normal_case.png | Bin
.../assets/preemption_priority_queue_case.png | Bin
.../assets/preemption_priorityclass_case.png | Bin
.../assets/preemption_quota_redistribution.png | Bin
.../assets/preemption_storm.png | Bin
.../assets/priority-flows.png | Bin
.../assets/priority-tree.png | Bin
.../assets/prometheus-cmd.png | Bin
.../assets/prometheus-web-ui-target-yunikorn.png | Bin
.../assets/prometheus-web-ui.png | Bin
.../assets/prometheus.png | Bin
.../assets/promtail.png | Bin
.../assets/queue-fairness.png | Bin
.../assets/queue-resource-quotas.png | Bin
.../assets/quota_check.png | Bin
...tion_successful_best_effort_preemption_case.png | Bin 0 -> 39146 bytes
...quota_preemption_successful_preemption_case.png | Bin 0 -> 45757 bytes
...ota_preemption_unsuccessful_preemption_case.png | Bin 0 -> 33860 bytes
.../assets/ray_cluster_cluster.png | Bin
.../assets/ray_cluster_on_ui.png | Bin
.../assets/ray_cluster_operator.png | Bin
.../assets/ray_cluster_ray_dashborad.png | Bin
.../assets/ray_job_job.png | Bin
.../assets/ray_job_on_ui.png | Bin
.../assets/ray_job_ray_dashboard.png | Bin
.../assets/resilience-node-recovery.jpg | Bin
.../assets/resilience-workflow.jpg | Bin
.../run-ray-service-kuberay-dashboard-ui.png | Bin
...run-ray-service-kuberay-service-api-testing.png | Bin
.../assets/run-ray-service-kuberay-service-pod.png | Bin
.../assets/run-ray-service-yunikorn-ui.png | Bin
.../assets/scheduling_no_predicate_4k.png | Bin
.../assets/scheduling_with_predicate_4k_.png | Bin
.../assets/simple_preemptor.png | Bin
.../assets/sparkResult.png | Bin
.../assets/tf-job-gpu-on-logs.png | Bin
.../assets/tf-job-gpu-on-ui.png | Bin
.../assets/tf-job-on-ui.png | Bin
.../assets/throughput.png | Bin
.../assets/throughput_3types.png | Bin
.../assets/throughput_conf.png | Bin
.../assets/translationBuilding.png | Bin
.../assets/translationDemo.png | Bin
.../assets/ug_lookup.png | Bin
.../assets/yk-ui-screenshots.gif | Bin
.../assets/yunikorn-gpu-time-slicing.png | Bin
.../assets/yunirkonVSdefault.png | Bin
.../design/architecture.md | 0
.../design/cache_removal.md | 2 +-
.../design/config_v2.md | 0
.../design/foreign_pod_tracking.md | 0
.../design/gang_scheduling.md | 30 +-
.../design/generic_resource.md | 0
.../design/historical_usage_tracking.md | 0
.../design/interface_message_simplification.md | 0
.../design/preemption.md | 2 +-
.../design/priority_scheduling.md | 0
.../version-1.8.0/design/quota_preemptor.md | 223 ++
.../design/resilience.md | 0
.../design/scheduler_configuration.md | 13 +-
.../design/scheduler_plugin.md | 0
.../design/simple_preemptor.md | 0
.../design/user_group_enforcement.md | 0
.../design/user_group_handling.md | 0
.../design/user_group_manager.md | 0
.../developer_guide/build.md | 0
.../developer_guide/dependencies.md | 8 +-
.../developer_guide/deployment.md | 0
.../developer_guide/e2e_test.md | 0
.../developer_guide/env_setup.md | 2 +-
.../developer_guide/openshift_development.md | 0
.../developer_guide/scheduler_object_states.md | 0
.../get_started/core_features.md | 0
.../get_started/get_started.md | 0
.../get_started/version.md | 3 +
versioned_docs/version-1.8.0/metrics/queue.md | 71 +
.../metrics/runtime.md | 0
.../metrics/scheduler.mdx | 0
.../evaluate_perf_function_with_kubemark.md | 0
.../evaluate_perf_function_with_kwok.md | 0
.../performance/metrics.md | 3 +
.../performance/performance_tutorial.md | 28 +-
.../performance/profiling.md | 0
.../user_guide/acls.md | 0
.../user_guide/deployment_modes.md | 0
.../user_guide/event_system.md | 0
.../user_guide/gang_scheduling.md | 0
.../labels_and_annotations_in_yunikorn.md | 14 +-
.../user_guide/observability/loki.md | 0
.../user_guide/observability/prometheus.md | 18 +-
.../user_guide/placement_rules.md | 2 +-
.../user_guide/preemption.md | 0
.../user_guide/priorities.md | 0
.../user_guide/queue_config.md | 44 +-
.../version-1.8.0/user_guide/quota_preemption.md | 119 ++
.../user_guide/resource_quota_mgmt.md | 0
.../user_guide/service_config.md | 0
.../user_guide/sorting_policies.md | 0
.../user_guide/troubleshooting.md | 0
.../user_guide/use_case.md | 4 +-
.../user_guide/usergroup_resolution.md | 0
.../workloads/kuberay/_ray_crd_yunikorn_config.mdx | 0
.../user_guide/workloads/kuberay/_ray_operator.mdx | 0
.../user_guide/workloads/run_flink.md | 0
.../user_guide/workloads/run_mpi.md | 0
.../user_guide/workloads/run_nvidia.md | 0
.../user_guide/workloads/run_ray_cluster.md | 0
.../user_guide/workloads/run_ray_job.md | 0
.../user_guide/workloads/run_ray_service.md | 0
.../user_guide/workloads/run_spark.md | 0
.../user_guide/workloads/run_tensorflow.md | 0
.../workloads/utils/_yunikorn_configmap_patch.mdx | 0
.../user_guide/workloads/workload_overview.md | 0
versioned_sidebars/version-1.5.0-sidebars.json | 106 -
versioned_sidebars/version-1.5.1-sidebars.json | 108 -
versioned_sidebars/version-1.6.0-sidebars.json | 118 --
versioned_sidebars/version-1.6.1-sidebars.json | 118 --
...2-sidebars.json => version-1.8.0-sidebars.json} | 2 +
versions.json | 6 +-
828 files changed, 762 insertions(+), 71432 deletions(-)
diff --git a/doap_YuniKorn.rdf b/doap_YuniKorn.rdf
index 058aa2bd8a..5c79bf9a6a 100644
--- a/doap_YuniKorn.rdf
+++ b/doap_YuniKorn.rdf
@@ -34,27 +34,42 @@
<programming-language>Go</programming-language>
<programming-language>JavaScript</programming-language>
<category rdf:resource="https://projects.apache.org/category/cloud" />
+ <release>
+ <Version>
+ <name>YuniKorn 1.8.0</name>
+ <created>2026-02-03</created>
+ <revision>1.8.0</revision>
+ </Version>
+ </release>
<release>
<Version>
<name>YuniKorn 1.7.0</name>
<created>2025-07-28</created>
<revision>1.7.0</revision>
</Version>
+ </release>
+ <release>
<Version>
<name>YuniKorn 1.6.3</name>
<created>2025-05-06</created>
<revision>1.6.3</revision>
</Version>
+ </release>
+ <release>
<Version>
<name>YuniKorn 1.6.2</name>
<created>2025-03-18</created>
<revision>1.6.2</revision>
</Version>
+ </release>
+ <release>
<Version>
<name>YuniKorn 1.6.1</name>
<created>2025-01-24</created>
<revision>1.6.1</revision>
</Version>
+ </release>
+ <release>
<Version>
<name>YuniKorn 1.6.0</name>
<created>2024-09-17</created>
diff --git a/docs/get_started/version.md b/docs/get_started/version.md
index 34d44606a4..df5af29d2e 100644
--- a/docs/get_started/version.md
+++ b/docs/get_started/version.md
@@ -57,4 +57,7 @@ Older build dependencies in earlier releases could prevent you from using some n
| 1.29.x | 1.5.0 | - |
| 1.30.x | 1.6.0 | - |
| 1.31.x | 1.6.0 | - |
+| 1.32.x | 1.7.0 | - |
+| 1.33.x | 1.8.0 | - |
+| 1.34.x | 1.8.0 | - |
diff --git a/docusaurus.config.js b/docusaurus.config.js
index 75ce528fab..521e7ac129 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -49,7 +49,7 @@ module.exports = {
announcementBar: {
id: 'new_release',
content:
- '1.7.0 has been released, check the <a href="/community/download">DOWNLOADS</a>.',
+ '1.8.0 has been released, check the <a href="/community/download">DOWNLOADS</a>.',
backgroundColor: '#fafbfc',
textColor: '#091E42',
},
diff --git a/src/pages/community/download.md b/src/pages/community/download.md
index 575bec04da..d2c67a9f16 100644
--- a/src/pages/community/download.md
+++ b/src/pages/community/download.md
@@ -31,13 +31,13 @@ All release artifacts should be checked for tampering using GPG or SHA-512.
We publish prebuilt docker images for everyone's convenience.
-The latest release of Apache YuniKorn is v1.6.3.
+The latest release of Apache YuniKorn is v1.8.0.
-| Version | Release date | Source download | Docker images [...]
-|---------|--------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
-| v1.7.0 | 2025-07-28 | [Download](https://www.apache.org/dyn/closer.lua/yunikorn/1.7.0/apache-yunikorn-1.7.0-src.tar.gz)<br/>[Checksum](https://downloads.apache.org/yunikorn/1.7.0/apache-yunikorn-1.7.0-src.tar.gz.sha512) & [Signature](https://downloads.apache.org/yunikorn/1.7.0/apache-yunikorn-1.7.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.7.0/images/sha256-51262e07493f9beadf4488aefc23877d553597bfb0705b00303e88470ae98ae4)<br/>[admission [...]
-| v1.6.3 | 2025-05-06 | [Download](https://www.apache.org/dyn/closer.lua/yunikorn/1.6.3/apache-yunikorn-1.6.3-src.tar.gz)<br/>[Checksum](https://downloads.apache.org/yunikorn/1.6.3/apache-yunikorn-1.6.3-src.tar.gz.sha512) & [Signature](https://downloads.apache.org/yunikorn/1.6.3/apache-yunikorn-1.6.3-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.6.3/images/sha256-093cea908ac49b8c2434db3b7b7eb3c0015f0a401af8c20da2b42f7bb42ebfff)<br/>[admission [...]
-| v1.6.2 | 2025-03-18 | [Download](https://archive.apache.org/dist/yunikorn/1.6.2/apache-yunikorn-1.6.2-src.tar.gz)<br/>[Checksum](https://archive.apache.org/dist/yunikorn/1.6.2/apache-yunikorn-1.6.2-src.tar.gz.sha512) & [Signature](https://darchive.apache.org/dist/yunikorn/1.6.2/apache-yunikorn-1.6.2-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.6.2/images/sha256-f7493e1be1e71a5c01d43367bda3240e41f9c801da27d8491f9827fda9aa1fac)<br/>[admission [...]
+| Version | Release date | Source download | Docker images [...]
+|---------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
+| v1.8.0 | 2026-02-03 | [Download](https://www.apache.org/dyn/closer.lua/yunikorn/1.8.0/apache-yunikorn-1.8.0-src.tar.gz)<br/>[Checksum](https://downloads.apache.org/yunikorn/1.8.0/apache-yunikorn-1.7.0-src.tar.gz.sha512) & [Signature](https://downloads.apache.org/yunikorn/1.8.0/apache-yunikorn-1.8.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.8.0/images/sha256-e038326d0dca5990d2f4505aa799bc46f70e95d73929fef5ff9ad98926c30822)<br/>[admission- [...]
+| v1.7.0 | 2025-05-06 | [Download](https://archive.apache.org/dist/yunikorn/1.7.0/apache-yunikorn-1.7.0-src.tar.gz)<br/>[Checksum](https://downloads.apache.org/yunikorn/1.7.0/apache-yunikorn-1.7.0-src.tar.gz.sha512) & [Signature](https://downloads.apache.org/yunikorn/1.7.0/apache-yunikorn-1.7.0-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.7.0/images/sha256-51262e07493f9beadf4488aefc23877d553597bfb0705b00303e88470ae98ae4)<br/>[admission- [...]
+| v1.6.3 | 2025-05-06 | [Download](https://archive.apache.org/dist/yunikorn/1.6.3/apache-yunikorn-1.6.3-src.tar.gz)<br/>[Checksum](https://downloads.apache.org/yunikorn/1.6.3/apache-yunikorn-1.6.3-src.tar.gz.sha512) & [Signature](https://downloads.apache.org/yunikorn/1.6.3/apache-yunikorn-1.6.3-src.tar.gz.asc) | [scheduler](https://hub.docker.com/layers/apache/yunikorn/scheduler-1.6.3/images/sha256-093cea908ac49b8c2434db3b7b7eb3c0015f0a401af8c20da2b42f7bb42ebfff)<br/>[admission- [...]
## Verifying the signature
diff --git a/src/pages/community/events.md b/src/pages/community/events.md
index 226fdf5cf0..25d9c9a70b 100644
--- a/src/pages/community/events.md
+++ b/src/pages/community/events.md
@@ -23,16 +23,8 @@ under the License.
-->
## Upcoming Events
-- KubeCon and CloudNativeCon 2023, Amsterdam
- _Scheduling Framework: Batch Extensions with Apache YuniKorn_
- https://sched.co/1Hydt (Thursday, April 20th 4.30PM CEST)
- Wilfred Spiegelenburg and Peter Bacsko (Cloudera)
-- KubeCon and CloudNativeCon 2023, Batch + HPC Day event, Amsterdam
- _SLA Aware Batch Scheduling in Apache YuniKorn with Multi-Tenant Preemption_
- https://sched.co/1Jo90 (Tuesday, April 18th 3.50PM CEST)
- Craig Condit and Sunil Govindan (Cloudera)
-Join us in person or virtual. We wil post links to the recordings of the sessions after they have been made available.
+None planned at this point.
---
@@ -54,28 +46,28 @@ A lot has changed since our last meetup a little over 6 months ago.
We since then have graduated to an Apache TLP, released v1.0.0 and two minor releases as a follow-up.
We had multiple presentations at: KubeCon Europe 2022, VISA Meetup and ApacheCON 2022.
This is just a partial list of all that has happened and is going to happen.
-
+
To add this event to your Google calendar [click here].
The invite includes a link for joining us virtually [using zoom webinar].
-We have the following agenda lined up:
-1. **YuniKorn @ Pinterest**
-Speaker : Rainie, Pinterest
+We have the following agenda lined up:
+1. **YuniKorn @ Pinterest**
+Speaker : Rainie, Pinterest
Abstract:
Spark on YARN is used for production workloads.
Using Apache YuniKorn we try to move from YARN to Kubernetes.
A path of testing, comparing and changing at multiple levels.
-2. **ApacheCON and YuniKorn : Feedback**
-Speaker : Wilfred, Cloudera
+2. **ApacheCON and YuniKorn : Feedback**
+Speaker : Wilfred, Cloudera
Abstract:
As a community we delivered two talks at ApacheCON NA.
How did we do and what was the feedback on our two talks.
Cloud native also had its own track: some observations from other talks.
-3. **YuniKorn roadmap**
-Speaker : Wilfred / Craig, Cloudera
+3. **YuniKorn roadmap**
+Speaker : Wilfred / Craig, Cloudera
Abstract:
-For YuniKorn 1.2 we have a roadmap defined around User Quotas, Application Priority and a K8s upgrade.
-Is that all we want and need. Do we want to add other things, and what do we want to do after this release?
+For YuniKorn 1.2 we have a roadmap defined around User Quotas, Application Priority and a K8s upgrade.
+Is that all we want and need. Do we want to add other things, and what do we want to do after this release?
There will also plenty of time to discuss community related things that are not on the agenda.
@@ -103,19 +95,26 @@ _Abstract_: Apache YuniKorn (Incubating) has released v0.11 earlier this year wi
like Gang scheduling, REST API enhancements and Kubernetes 1.19 support. In a month, we are planning the major
v1.0.0 release with Kubernetes 1.20 & 1.21 support, improved node sorting and numerous small fixes & enhancements! In this meetup, we will deep dive into the implementation of Gang scheduling behind the use of temporary
placeholder pods on Kubernetes, significant performance improvement with simplified scheduler core code and
-a new node sorting algorithm. Please find all the topics for this meetup [here](https://drive.google.com/file/d/1cbT3i6_kSvrvlj4M7OyNIvXohVrGRiEl/view?usp=sharing).
+a new node sorting algorithm. Please find all the topics for this meetup [here](https://drive.google.com/file/d/1cbT3i6_kSvrvlj4M7OyNIvXohVrGRiEl/view?usp=sharing).
----
## Past Conference & Meetup Recordings
-- KubeCon North America 2022, Batch & HPC day:
+- KubeCon North America 2025:
+ - [Optimized Scheduling for Big Data Workloads - The Why, What...](https://www.youtube.com/watch?v=_W83GgQof70) :busts_in_silhouette: Rahul Sharma, Wilfred Spiegelenburg
+ - [Panel: Cracking the Data Locality Puzzle](https://youtu.be/NUR0bFPchks) :busts_in_silhouette: Wilfred Spiegelenburg, Et al.
+- KubeCon Europe 2023: [Scheduling Framework: Batch Extensions with Apache YuniKorn](https://www.youtube.com/watch?v=ij2UQ9V4CBU) :busts_in_silhouette: Wilfred Spiegelenburg, Peter Bacsko
+- Data on Kubernetes Community: [Batch Workloads in Multi-tenant Environment with Apache YuniKorn](https://www.youtube.com/watch?v=8B8GNE-wl-g) :busts_in_silhouette: Wilfred Spiegelenburg, Sunil Govindan
+- Apache Community Over Code 2023 Apache YuniKorn: preemption for multi tenant Kubernetes clusters :busts_in_silhouette: Wilfred Spiegelenburg, Craig Condit
+- KubeCon North America 2023 [Migrating Hybrid Big Data Platforms at Scale to Kubernetes](https://www.youtube.com/watch?v=1NepjxK4XLM) :busts_in_silhouette: Sunil Govindan
+- KubeCon North America 2022 including Batch & HPC day:
- [Beyond Experimental: Spark on Kubernetes](https://www.youtube.com/watch?v=u7htKIiK75c) :busts_in_silhouette: Weiwei Yang, Bowen Li
- [Panel discussion: Batch scheduling on Kubernetes](https://www.youtube.com/watch?v=xQBkBRJdMCs) :busts_in_silhouette: Wilfred Spiegelenburg, Et al.
- Apache YuniKorn Meetup: [October 2022](https://youtu.be/l76NByMersg) | [Pinterest presentation](https://drive.google.com/file/d/1sSXRNx_ndk4mWaCICjtbddjoSUYN9TV7/view?usp=sharing) | [Cloudera presentation](https://drive.google.com/file/d/14jqfDNpCTTQr0R2ZBrghn-WGFBR89KI7/view?usp=sharing) :busts_in_silhouette: Wilfred Spiegelenburg, Rainie Li, Craig Condit
- ApacheCon North America 2022: [Apache YuniKorn Enhanced Scheduling in the Cloud](https://www.apachecon.com/acna2022/slides/03_Spiegelenburg_Apache-YuniKorn-Enhanced.pdf) :busts_in_silhouette: Wilfred Spiegelenburg, Manikandan Ramaraj
- VISA Data Meetup: [Apache YuniKorn scheduling Apache Spark on Kubernetes](https://web.cvent.com/event/9ceb73f1-4ce7-480e-95ed-fe65dea09cc4/websitePage:e6b9cca5-1c3b-4b7a-99e7-62c045b1ce26?i=bn_TynKrfUao8DzBYW3XwA&locale=en-US) :busts_in_silhouette: Wilfred Spiegelenburg
-- KubeCon Europe 2022, Batch & HPC day: [Apache YuniKorn A Kubernetes Scheduler Plugin for Batch Workloads](https://www.youtube.com/watch?v=cQD_jwA4fqo) :busts_in_silhouette: Wilfred Spiegelenburg, Craig Condit
+- KubeCon Europe 2022, Batch & HPC day: [Apache YuniKorn A Kubernetes Scheduler Plugin for Batch Workloads](https://www.youtube.com/watch?v=cQD_jwA4fqo) :busts_in_silhouette: Wilfred Spiegelenburg, Craig Condit
- ApacheCon 2021: [Next Level Spark on Kubernetes with Apache YuniKorn (Incubating)](https://youtu.be/gOST-iT-hj8) :busts_in_silhouette: Weiwei Yang, Chaoran Yu
- ApacheCon Asia 2021: [State Of The Union With Apache Yunikorn (Incubating) - Cloud Native Scheduler For Big Data Usecases](https://www.youtube.com/watch?v=c9UYxzqVMeg) :busts_in_silhouette: Julia Kinga Marton, Sunil Govindan
- Future of Data Meetup: [Apache YuniKorn: Cloud-native Resource Scheduling](https://www.youtube.com/watch?v=j-6ehu6GrwE) :busts_in_silhouette: Wangda Tan, Wilfred Spiegelenburg
diff --git a/src/pages/community/release_procedure.md b/src/pages/community/release_procedure.md
index b8fd797409..2d0579282a 100644
--- a/src/pages/community/release_procedure.md
+++ b/src/pages/community/release_procedure.md
@@ -57,9 +57,9 @@ The instructions and tools obey the ASF [release policy](http://www.apache.org/l
## Release Procedure
Simplified release procedure:
-1. Create a release branch for the target release in all git repos, such as `branch-1.3`
+1. Create a release branch for the target release in all git repos, such as `branch-1.8`
2. Stabilize the release by fixing test failures and bugs only
-3. Tag update release for a new version to prepare a release candidate, e.g `v1.3.0-1` for RC1
+3. Tag update release for a new version to prepare a release candidate, e.g `v1.8.0-1` for RC1
4. Update the CHANGELOG
5. Configure [release-configs.json](https://github.com/apache/yunikorn-release/tree/master/release-tools/release-configs.json)
6. Run script [build-release.py](https://github.com/apache/yunikorn-release/tree/master/release-tools/build-release.py) to generate source code tarball, checksum and signature.
@@ -70,23 +70,23 @@ Branching and tagging can, and in most cases will, require changes in the go mod
### Branching
Branching is part of the release preparation and often has happened some time before the release process starts.
-As an example the steps to create the branch for the `v1.3.0` release:
+As an example the steps to create the branch for the `v1.8.0` release:
```shell script
-git checkout -b branch-1.3 master
-git push -u origin branch-1.3
+git checkout -b branch-1.8 master
+git push -u origin branch-1.8
```
### Tag for RCs
A release needs to be tagged in git before starting the release process.
As an example check [YUNIKORN-358](https://issues.apache.org/jira/browse/YUNIKORN-358) and [YUNIKORN-1004](https://issues.apache.org/jira/browse/YUNIKORN-1004).
Release candidates should be tagged with the version **and** build number of the release candidate.
-For example artifacts used to build 1.3.0 RC1 should be tagged `v1.3.0-1`.
+For example artifacts used to build 1.8.0 RC1 should be tagged `v1.8.0-1`.
Releases are **not** created in GitHub for RCs.
-Example for creating an annotated tag on the checked out commit for RC1 for `v1.3.0`:
+Example for creating an annotated tag on the checked out commit for RC1 for `v1.8.0`:
```shell script
-git tag -a v1.3.0-1 -m "RC1 for v1.3.0"
-git push origin v1.3.0-1
+git tag -a v1.8.0-1 -m "RC1 for v1.8.0"
+git push origin v1.8.0-1
```
:::caution
Under **no** circumstances should an existing tag be removed or moved.
@@ -94,8 +94,8 @@ This will break golang dependency resolution for downstream users.
:::
### Update references based on tags
-The tagging is multistep process, all actions are done on the branch that will be released, like `branch-1.3`:
-1. Tag the web and scheduler interface with the release candidate tag: i.e. `v1.3.0-1`.
+The tagging is multistep process, all actions are done on the branch that will be released, like `branch-1.8`:
+1. Tag the web and scheduler interface with the release candidate tag: i.e. `v1.8.0-1`.
2. Update the `go.mod` file in the core using:
```shell script
go get github.com/apache/yunikorn-scheduler-interface
@@ -114,7 +114,7 @@ In the release artifacts a [CHANGELOG](https://github.com/apache/yunikorn-releas
The CHANGELOG should contain the list of jiras fixed in the release.
Follow these steps to generate the list:
- Go to the [releases page in jira](https://issues.apache.org/jira/projects/YUNIKORN?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released-unreleased)
-- Click on the version that is about to be released, i.e. `1.3.0`
+- Click on the version that is about to be released, i.e. `1.8.0`
- Click on the `Release Notes` link on the top of the page
- Click the button `Configure Release Notes`
- Select the style `Text` and click `create`
@@ -129,18 +129,18 @@ The tool requires a simple [json](https://github.com/apache/yunikorn-release/tre
This configuration points to the tag to use in the release and the version to release.
Update the version to release and the tag for each repository.
The version used must be the _exact_ version that you intend to release.
-So `0.12.2` or `1.3.0` **without** any additional references like a `RC1` or something similar.
+So `0.12.2` or `1.8.0` **without** any additional references like a `RC1` or something similar.
The version is used as part of the source code, inside the Makefile etc., and to name the release artefact and cannot be changed anymore.
The tag format is as described in the [step tag for released version](#tag-for-release)
-As an example when releasing the first release candidate for `1.3.0` the json file should contain version and tag information like below:
+As an example when releasing the first release candidate for `1.8.0` the json file should contain version and tag information like below:
```json
{
"release": {
- "version": "1.3.0"
+ "version": "1.8.0"
},
- "tag": "v1.3.0-1",
+ "tag": "v1.8.0-1",
"repository": "https://github..."
}
```
@@ -166,23 +166,23 @@ Run the release tool using the option `--sign <email-address>` to auto sign the
Manually creating the signature for the file generated by the tool:
```shell script
-gpg --local-user <email-address> --armor --output apache-yunikorn-1.3.0-src.tar.gz.asc --detach-sig apache-yunikorn-1.3.0-src.tar.gz
+gpg --local-user <email-address> --armor --output apache-yunikorn-1.8.0-src.tar.gz.asc --detach-sig apache-yunikorn-1.8.0-src.tar.gz
```
-This will create the signature in the file: `apache-yunikorn-1.3.0-src.tar.gz.asc`
+This will create the signature in the file: `apache-yunikorn-1.8.0-src.tar.gz.asc`
Verify that the signature is correct using:
```shell script
-gpg --verify apache-yunikorn-1.3.0-src.tar.gz.asc apache-yunikorn-1.3.0-src.tar.gz
+gpg --verify apache-yunikorn-1.8.0-src.tar.gz.asc apache-yunikorn-1.8.0-src.tar.gz
```
#### Create Checksum
This step is included in the release after generation of the source tar ball, if the release tool is used this step can be skipped.
```shell script
-shasum -a 512 apache-yunikorn-1.3.0-src.tar.gz > apache-yunikorn-1.3.0-src.tar.gz.sha512
+shasum -a 512 apache-yunikorn-1.8.0-src.tar.gz > apache-yunikorn-1.8.0-src.tar.gz.sha512
```
-This will create the checksum in the file: `apache-yunikorn-1.3.0-src.tar.gz.sha512`
+This will create the checksum in the file: `apache-yunikorn-1.8.0-src.tar.gz.sha512`
Verify that the checksum is correct using:
```shell script
-shasum -a 512 -c apache-yunikorn-1.3.0-src.tar.gz.sha512
+shasum -a 512 -c apache-yunikorn-1.8.0-src.tar.gz.sha512
```
### Upload Release Candidate Artifacts
@@ -193,7 +193,7 @@ The release artifacts consist of three parts:
The three artefacts need to be uploaded to: `https://dist.apache.org/repos/dist/dev/yunikorn/`
-Create a release directory based on the version, i.e. `1.3.0`, add the three files to directory.
+Create a release directory based on the version, i.e. `1.8.0`, add the three files to directory.
Commit the changes.
If you have not done so already make sure to [add your signature](#add-the-signature-to-the-project-keys-file) to the KEYS file.
@@ -207,14 +207,14 @@ A voting thread must be created on `dev@yunikorn.apache.org` and run for at leas
At least three +1 votes are required and more +1 votes than -1 votes.
### Tag for release
-Once the release has passed voting, git tags and GitHub releases should be created for final release tag, example `v1.3.0`
-The final tag must point to the same commit as the approved release candidate tag, example `v1.3.0-1`
+Once the release has passed voting, git tags and GitHub releases should be created for final release tag, example `v1.8.0`
+The final tag must point to the same commit as the approved release candidate tag, example `v1.8.0-1`
Check the step [Create the GIT releases](#create-the-git-releases) later in the procedure for the release updates.
Adding the final release tag, again annotated, on the checked out commit:
```shell script
-git tag -a v1.3.0 -m "Apache YuniKorn v1.3.0"
-git push origin v1.3.0
+git tag -a v1.8.0 -m "Apache YuniKorn v1.8.0"
+git push origin v1.8.0
```
### Publish the Release
@@ -314,8 +314,8 @@ Helm charts _must_ be signed on release.
Contrary to the source code tar ball signing, signing the helm charts requires manual entry of the key passphrase.
There is no option to provide the passphrase any other way to the helm tool.
The helm package will generate two files:
-- helm package: example `yunikorn-1.3.0.tgz`
-- provenance or signature file: example `yunikorn-1.3.0.tgz.prov`
+- helm package: example `yunikorn-1.8.0.tgz`
+- provenance or signature file: example `yunikorn-1.8.0.tgz.prov`
Both files _must_ be attached to the [release in GIT](#create-the-git-releases) for the release repository.
@@ -325,7 +325,7 @@ First the `index.yaml` file:
The `digest` mentioned in the index.yaml file is the digest that gets printed by the tool (unsigned package) or stored in the provenance file.
It can be generated manually using:
```shell script
-shasum -a 256 yunikorn-1.3.0.tgz
+shasum -a 256 yunikorn-1.8.0.tgz
```
:::caution
@@ -345,7 +345,7 @@ Any change in supported Kubernetes versions _must_ be mentioned in the [release
- Create a new documentation version on YuniKorn website based on the latest content in the `docs` directory.
Refer to [these steps](#version-the-documentation) on how to create the new documentation version.
- Create the release announcement to be referenced from download page on the website.
- The release announcement is a markdown file based on the version: `1.3.0.md`.
+ The release announcement is a markdown file based on the version: `1.8.0.md`.
The steps on how to create the [release announcement](#release-announcement) explains the content and where to add the file.
- Update the [download page](/community/download) of the website as per the [steps](#update-the-download-page).
@@ -404,10 +404,10 @@ Open a PR and commit all the changes below to the **master** branch, once the au
Documentation versioning uses the simple **MAJOR.MINOR.PATCH** semver version of the release.
This means no letters, release candidate tags or anything like that:
```shell script
-yarn release 1.3.0
+pnpm release 1.8.0
```
This command will snapshot all the docs from the current `docs` directory, and copy all files to another new directory
-under `versioned_docs`, e.g `versioned_docs/version-1.3.0`.
+under `versioned_docs`, e.g `versioned_docs/version-1.8.0`.
A similar copy will be generated for the sidebar under `versioned_sidebars` that belongs to the documentation version.
This process will also update the `version.json` file in the root and add the new release as a line item.
@@ -422,7 +422,7 @@ All committers have access to the filter and can update the version to be checke
The file name must be the same as the semver version of the release without the 'v':
```
-src/pages/release-announce/1.3.0.md
+src/pages/release-announce/1.8.0.md
```
All releases are automatically added to the [index list](https://yunikorn.apache.org/release-announce/).
@@ -451,7 +451,7 @@ Duplicate the first row of the table and change the links and details to reflect
All links must be updated:
* 3 for the download (source tar, checksum and signature)
* 3 for the docker images (scheduler, admission controller and web)
-* 1 release announcement using a link in the form of `/release-announce/1.3.0`
+* 1 release announcement using a link in the form of `/release-announce/1.8.0`
For the second row update the download links for the source tar, checksum and signature.
diff --git a/src/pages/community/roadmap.md b/src/pages/community/roadmap.md
index 4a88346712..e31ca755fc 100644
--- a/src/pages/community/roadmap.md
+++ b/src/pages/community/roadmap.md
@@ -25,33 +25,33 @@ under the License.
# Kubernetes version support
Supported Kubernetes versions and the Kubernetes dependency will be defined and finalised during the development cycle.
-Current build dependency: 1.27
+Current build dependency: 1.34
# Next Release Development
Release Details:
-- Version: 1.5.0
-- Target release date: February / March 2024
+- Version: 1.9.0
+- Target release date: May 2026
- Release manager: undecided
- Development status: [Issue tracker](https://issues.apache.org/jira/issues/?filter=12348416)
Planned major features:
-- [YUNIKORN-970](https://issues.apache.org/jira/browse/YUNIKORN-970) Change queue metrics to labeled
-- [YUNIKORN-1544](https://issues.apache.org/jira/browse/YUNIKORN-1544) User and group quota enforcement - Phase 2
-- [YUNIKORN-2099](https://issues.apache.org/jira/browse/YUNIKORN-2099) [Umbrella] K8shim simplification
-- [YUNIKORN-2115](https://issues.apache.org/jira/browse/YUNIKORN-2125) [Umbrella] Application tracking history - Phase 2
-- [YUNIKORN-1362](https://issues.apache.org/jira/browse/YUNIKORN-1362) filtering nodes in UI
+- [YUNIKORN-3211](https://issues.apache.org/jira/browse/YUNIKORN-3211) K8s 1.35 support
+- [YUNIKORN-3117](https://issues.apache.org/jira/browse/YUNIKORN-3117) DRA GA in K8s 1.34
+- [YUNIKORN-3058](https://issues.apache.org/jira/browse/YUNIKORN-3058) [UMBRELLA] Support InPlacePodVerticalScaling (phase 3)
+- [YUNIKORN-3210](https://issues.apache.org/jira/browse/YUNIKORN-3210) Remove plugin code
+- [YUNIKORN-3122](https://issues.apache.org/jira/browse/YUNIKORN-3122) Optimize Node Evaluation by Pre-filtering Tainted Nodes
+- [YUNIKORN-3203](https://issues.apache.org/jira/browse/YUNIKORN-3203) [Umbrella] Quota change enforcement via preemption
+- [YUNIKORN-3192](https://issues.apache.org/jira/browse/YUNIKORN-3192) Queue configuration management
+- [YUNIKORN-3118](https://issues.apache.org/jira/browse/YUNIKORN-3118) Implement Parallel TryNode Evaluation
+
+Minor changes and important bugs:
+- [YUNIKORN-3025](https://issues.apache.org/jira/browse/YUNIKORN-3025) Support for application-level preemption
- [YUNIKORN-1727](https://issues.apache.org/jira/browse/YUNIKORN-1727) build info extension
-- [YUNIKORN-1922](https://issues.apache.org/jira/browse/YUNIKORN-1922) display pending resources in web UI
-- [YUNIKORN-2140](https://issues.apache.org/jira/browse/YUNIKORN-2140) Web UI: resource display rework
-- [no jira yet] display preemption info in web UI
-
+- [YUNIKORN-3132](https://issues.apache.org/jira/browse/YUNIKORN-3132) Placeholder deployment hardening
+- [multiple jiras] Web UI updates to expose
# Future development: long term goals
-- [YUNIKORN-22](https://issues.apache.org/jira/browse/YUNIKORN-22) Partition support for nodes
-- [YUNIKORN-1728](https://issues.apache.org/jira/browse/YUNIKORN-1728) Percentage support for queue max app and resources
-- Queue type change from leaf to parent and reverse
-- moving applications from queue to queue
-- compressed queue config (configmap 1MB limit)
-- reproducible builds
+- [YUNIKORN-2985](https://issues.apache.org/jira/browse/YUNIKORN-2985) [Umbrella] Foreign pod preemption
+- [YUNIKORN-1546](https://issues.apache.org/jira/browse/YUNIKORN-1546) [Umbrella] Allow changing queue type
- FIPS builds
diff --git a/src/pages/release-announce/1.8.0.md b/src/pages/release-announce/1.8.0.md
new file mode 100644
index 0000000000..a946fc1928
--- /dev/null
+++ b/src/pages/release-announce/1.8.0.md
@@ -0,0 +1,123 @@
+---
+id: rn-1.8.0
+title: Release Announcement v1.8.0
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Release Announcement v1.8.0
+
+We are pleased to announce that the Apache YuniKorn community has voted to release 1.8.0.
+Apache YuniKorn is a standalone resource scheduler, designed for managing and scheduling Batch and Data workloads on container
+orchestration frameworks like Kubernetes for on-prem and on-cloud use cases.
+
+## Overview
+
+The Apache YuniKorn community has resolved 93 [JIRAs](https://issues.apache.org/jira/issues/?filter=12353913) in this release.
+
+Release manager: Wilfred Spiegelenburg
+
+Release date: 2026-02-03
+
+## Plugin mode removal
+As per the documented deprecation and removal of the plugin mode the first step is part of this release.
+The convenience binary will no longer be published for this release. The binary can still be build if required via the normal build process.
+During the development cycle of YuniKorn 1.9 the implementation of the plugin will be gradually removed.
+
+All deployments that use the plugin should plan on a migration to the standard mode in preparation of the YuniKorn 1.9 release.
+
+## Highlights
+
+### Kubernetes 1.33 and 1.34 support
+Apache YuniKorn 1.8.0 add supports for Kubernetes 1.33 and Kubernetes 1.34.
+See [YUNIKORN-3156](https://issues.apache.org/jira/browse/YUNIKORN-3156) for details.
+
+### LDAP group resolver
+LDAP resolution is a popular method to resolve group memberships. A new group resolver has been added as a tech preview to the release.
+See [YUNIKORN-656](https://issues.apache.org/jira/browse/YUNIKORN-656) for details.
+
+### Quota change enforcement via preemption
+Changing a queue quota would be a simple quota change. The new quota would be enforced but no action was taken to make sure the usage would not exceed the new quota.
+In YuniKorn 1.8.0 an option is now added to trigger preemption to bring usage down to within the newly assigned quota.
+See [YUNIKORN-3133](https://issues.apache.org/jira/browse/YUNIKORN-3133) for details.
+
+### Skip scheduling application if too many pods are unschedulable
+If an application has too many unschedulable pods, it can drastically affect scheduling throughput.
+Only checking a limited number of requests per application limits the impact that large numbers of pending requests have on the scheduling throughput.
+
+Two new properties are added to the queue configuration properties: `application.unschedasks.backoff` and `application.unschedasks.backoff.delay`.
+Backoff sets the number of requests to check before triggering backoff. The default is 0 (off), a value greater than 0 must be set on the queue to trigger backoff.
+The delay is a Golang duration in string form. The default is 30 seconds.
+See [YUNIKORN-3115](https://issues.apache.org/jira/browse/YUNIKORN-3115) for details.
+
+### Preemption Hardening (Phase 2)
+Preemption now looks at the individual resources types requested in the request and maps that to resources provided by the victim.
+That same view is applied also when looking at a queue to decide if it is over guaranteed or not. A queue can now be over or below guaranteed for a single resource type.
+That allows a wider selection of queues and better victim selection.
+
+A race condition between the release of a placeholder and the preemptor selecting that same allocation for preemption has been fixed.
+See [YUNIKORN-2872](https://issues.apache.org/jira/browse/YUNIKORN-2872) for details.
+
+## Deprecations
+
+### Removal of legacy user processing
+Legacy user handling via the label `yunikorn.apache.org/username` will be removed in YuniKorn 1.9. The label method was deprecated in YuniKorn 1.6.
+YuniKorn 1.9 will only support the pod annotations for user details.
+See [YUNIKORN-2634](https://issues.apache.org/jira/browse/YUNIKORN-2634) for details.
+
+### Documentation update
+The documentation for some older point releases has been removed. The latest patch release of each minor version has been retained.
+The following documentation sets have been removed:
+- 1.5.0
+- 1.5.1
+- 1.6.0
+- 1.6.1
+- 1.6.2
+
+## YuniKorn 1.7.0 release note addendum
+During the YuniKorn 1.7.0 release some references to important changes were missed. The release notes for 1.7.0 are missing the following crucial references:
+
+### Change default volume binding timeout to 10 minutes
+The default volume bind timeout has been corrected to the default used by Kubernetes.
+It was incorrectly set to 10 seconds instead of 10 minutes causing unexpected scheduling failure in clusters with slow volume binding.
+See [YUNIKORN-3021](https://issues.apache.org/jira/browse/YUNIKORN-3021) for details.
+
+### Statedump endpoint change
+The scheduler statedump has permanently moved from the webservice endpoint to the debug endpoint. The debug endpoint is not accessible via the poxy in the WEB UI container.
+The data exposed in the debug endpoint is not meant for generic consumption and could contain information that should only be accessed by administrators.
+See [YUNIKORN-2965](https://issues.apache.org/jira/browse/YUNIKORN-2965) for details.
+
+### Internal object removal
+Some REST endpoints were exposing internal objects. Those objects were never designed to be exposed. Accessing them via REST could cause issues during the scheduling cycle.
+The objects have been removed from the application REST response.
+See [YUNIKORN-2925](https://issues.apache.org/jira/browse/YUNIKORN-2925) for details.
+
+### Metadata consistency warning
+A warning is emitted if a pod has inconsistent metadata. The k8shim emits the warning to alert the administrator that behaviour might not be as expected.
+See [YUNIKORN-2811](https://issues.apache.org/jira/browse/YUNIKORN-2811) for details.
+
+## Community update
+Mit Desai was added as a new committer.
+
+## Credits
+The YuniKorn 1.8.0 release would not have been possible without the hard work of our community, and we would like to thank the following contributors to this release:
+
+> Adrian Lin, Craig Condit, Hank Hunang, Hsien-Cheng(Ryan) Huang, HUANG CHEN YI, Kaichia Chen, Kang-Li Wu, Kuo-Hao Huang, Manikandan R, Michael Chu, Mit Desai,
+> Peter Bacsko, Po Han Huang, Shravan Achar, Shubham Mishra, Tyler E Denton, Wilfred Spiegelenburg
diff --git a/versioned_docs/version-1.5.0/api/cluster.md b/versioned_docs/version-1.5.0/api/cluster.md
deleted file mode 100644
index 35e98dac44..0000000000
--- a/versioned_docs/version-1.5.0/api/cluster.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-id: cluster
-title: Cluster
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Clusters
-
-Returns general information about the clusters managed by the YuniKorn Scheduler.
-The response includes build information about resource managers.
-
-**URL** : `/ws/v1/clusters`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-As an example, here is a response from a cluster with 1 resource manager.
-
-```json
-[
- {
- "startTime": 1697100824863892713,
- "rmBuildInformation": [
- {
- "arch": "amd64",
- "buildDate": "2023-09-04T18:11:43+0800",
- "buildVersion": "latest",
- "coreSHA": "0ecf24d2aad2",
- "goVersion": "1.21",
- "isPluginVersion": "false",
- "rmId": "mycluster",
- "shimSHA": "8b26c373b4b5",
- "siSHA": "e7622cf54e95"
- }
- ],
- "partition": "default",
- "clusterName": "kubernetes"
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
diff --git a/versioned_docs/version-1.5.0/api/scheduler.md b/versioned_docs/version-1.5.0/api/scheduler.md
deleted file mode 100644
index 1ab0c644ce..0000000000
--- a/versioned_docs/version-1.5.0/api/scheduler.md
+++ /dev/null
@@ -1,2152 +0,0 @@
----
-id: scheduler
-title: Scheduler
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Overview
-
-The scheduler REST API returns information about various objects used by the YuniKorn Scheduler.
-
-Many of these APIs return collections of resources. Internally, all resources are represented as raw
-64-bit signed integer types. When interpreting responses from the REST API, resources of type `memory`
-are returned in units of bytes while resources of type `vcore` are returned in units of millicores
-(thousands of a core). All other resource types have no specific unit assigned.
-
-Under the `allocations` field in the response content for the app/node-related calls in the following spec, `placeholderUsed` refers to whether or not the allocation is a replacement for a placeholder. If true, `requestTime` is the creation time of its placeholder allocation, otherwise it's that of the allocation's ask. `allocationTime` is the creation time of the allocation, and `allocationDelay` is simply the difference between `allocationTime` and `requestTime`.
-
-## Partitions
-
-Returns general information and statistics about a partition.
-
-**URL** : `/ws/v1/partitions`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```json
-[
- {
- "clusterId": "mycluster",
- "name": "default",
- "state": "Active",
- "lastStateTransitionTime": 1649167576110754000,
- "capacity": {
- "capacity": {
- "ephemeral-storage": 188176871424,
- "hugepages-1Gi": 0,
- "hugepages-2Mi": 0,
- "memory": 1000000000,
- "pods": 330,
- "vcore": 1000
- },
- "usedCapacity": {
- "memory": 800000000,
- "vcore": 500
- },
- "utilization": {
- "memory": 80,
- "vcore": 50
- }
- },
- "nodeSortingPolicy": {
- "type": "fair",
- "resourceWeights": {
- "memory": 1.5,
- "vcore": 1.3
- }
- },
- "applications": {
- "New": 5,
- "Pending": 5,
- "total": 10
- },
- "totalContainers": 0,
- "totalNodes": 2
- },
- {
- "clusterId": "mycluster",
- "name": "gpu",
- "state": "Active",
- "lastStateTransitionTime": 1649167576111236000,
- "capacity": {
- "capacity": {
- "memory": 2000000000,
- "vcore": 2000
- },
- "usedCapacity": {
- "memory": 500000000,
- "vcore": 300
- },
- "utilization": {
- "memory": 25,
- "vcore": 15
- }
- },
- "nodeSortingPolicy": {
- "type": "binpacking",
- "resourceWeights": {
- "memory": 0,
- "vcore": 4.11
- }
- },
- "applications": {
- "New": 5,
- "Running": 10,
- "Pending": 5,
- "total": 20
- },
- "totalContainers": 20,
- "totalNodes": 5
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Queues
-
-### Partition queues
-
-Fetch all Queues associated with given Partition and displays general information about the queues like name, status, capacities and properties.
-The queues' hierarchy is kept in the response json.
-
-**URL** : `/ws/v1/partition/{partitionName}/queues`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-For the default queue hierarchy (only `root.default` leaf queue exists) a similar response to the following is sent back to the client:
-
-```json
-[
- {
- "queuename": "root",
- "status": "Active",
- "maxResource": {
- "ephemeral-storage": 188176871424,
- "hugepages-1Gi": 0,
- "hugepages-2Mi": 0,
- "memory": 8000000000,
- "pods": 330,
- "vcore": 8000
- },
- "guaranteedResource": {
- "memory": 54000000,
- "vcore": 80
- },
- "allocatedResource": {
- "memory": 54000000,
- "vcore": 80
- },
- "pendingResource": {
- "memory": 54000000,
- "vcore": 80
- },
- "isLeaf": "false",
- "isManaged": "false",
- "properties": {
- "application.sort.policy": "stateaware"
- },
- "parent": "",
- "template": {
- "maxResource": {
- "memory": 8000000000,
- "vcore": 8000
- },
- "guaranteedResource": {
- "memory": 54000000,
- "vcore": 80
- },
- "properties": {
- "application.sort.policy": "stateaware"
- }
- },
- "partition": "default",
- "children": [
- {
- "queuename": "root.default",
- "status": "Active",
- "maxResource": {
- "memory": 8000000000,
- "vcore": 8000
- },
- "guaranteedResource": {
- "memory": 54000000,
- "vcore": 80
- },
- "allocatedResource": {
- "memory": 54000000,
- "vcore": 80
- },
- "pendingResource": {
- "memory": 54000000,
- "vcore": 80
- },
- "isLeaf": "true",
- "isManaged": "false",
- "properties": {
- "application.sort.policy": "stateaware"
- },
- "parent": "root",
- "template": null,
- "children": [],
- "absUsedCapacity": {
- "memory": 1,
- "vcore": 0
- },
- "maxRunningApps": 12,
- "runningApps": 4,
- "allocatingAcceptedApps": [
- "app-1",
- "app-2"
- ]
- }
- ],
- "absUsedCapacity": {
- "memory": 1,
- "vcore": 0
- }
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Applications
-
-### Partition applications
-
-Fetch all Applications for the given Partition/State combination and displays general information about the applications like used resources, queue name, submission time and allocations.
-Only following application states are allowed: active, rejected, completed. Active is a fake state that represents all application states except completed and rejected.
-For active state, can narrow the result by status query parameters(case-insensitive). For example, can fetch `Running` applications for the default partition by
-`/ws/v1/partition/default/applications/active?status=running`.
-
-**URL** : `/ws/v1/partition/:partition/applications/:state`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-The content of the application object is the same as Queue Applications. See
- [Queue Applications](#queue-applications) for details.
-
-### Queue applications
-
-Fetch all Applications for the given Partition/Queue combination and displays general information about the applications like used resources, queue name, submission time and allocations.
-
-**URL** : `/ws/v1/partition/{partitionName}/queue/{queueName}/applications`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Deprecated**:
-
-Field `uuid` has been deprecated, would be removed from below response in YUNIKORN 1.7.0 release. `AllocationID` has replaced `uuid`. Both `uuid` and `AllocationID` fields have the same value. `AllocationID` has extra suffix containing hyphen and counter (-0, -1 and so on) at the end.
-
-**Content examples**
-
-In the example below there are three allocations belonging to two applications, one with a pending request.
-
-```json
-[
- {
- "applicationID": "application-0001",
- "usedResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "maxUsedResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "pendingResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "partition": "default",
- "queueName": "root.default",
- "submissionTime": 1648754032076020293,
- "requests": [
- {
- "allocationKey": "f137fab6-3cfa-4536-93f7-bfff92689382",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0001",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task2"
- },
- "requestTime": 16487540320812345678,
- "resource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "pendingCount": 1,
- "priority": "0",
- "requiredNodeId": "",
- "applicationId": "application-0001",
- "partition": "default",
- "placeholder": false,
- "placeholderTimeout": 0,
- "taskGroupName": "",
- "allocationLog": [
- {
- "message": "node(s) didn't match Pod's node affinity, node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate",
- "lastOccurrence": 16487540320812346001,
- "count": 81
- },
- {
- "message": "node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, node(s) didn't match Pod's node affinity",
- "lastOccurrence": 16487540320812346002,
- "count": 504
- },
- {
- "message": "node(s) didn't match Pod's node affinity",
- "lastOccurrence": 16487540320812346003,
- "count": 1170
- }
- ]
- }
- ],
- "allocations": [
- {
- "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0001",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task0"
- },
- "requestTime": 1648754034098912461,
- "allocationTime": 1648754035973982920,
- "allocationDelay": 1875070459,
- "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
- "allocationID": "9af35d44-2d6f-40d1-b51d-758859e6b8a8-0",
- "resource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "priority": "0",
- "nodeId": "node-0001",
- "applicationId": "application-0001",
- "partition": "default",
- "placeholder": false,
- "placeholderUsed": true
- }
- ],
- "applicationState": "Running",
- "user": "system:serviceaccount:kube-system:deployment-controller",
- "groups": [
- "system:serviceaccounts",
- "system:serviceaccounts:kube-system",
- "system:authenticated"
- ],
- "rejectedMessage": "",
- "stateLog": [
- {
- "time": 1648741409145224000,
- "applicationState": "Accepted"
- },
- {
- "time": 1648741409145509400,
- "applicationState": "Starting"
- },
- {
- "time": 1648741409147432100,
- "applicationState": "Running"
- }
- ],
- "placeholderData": [
- {
- "taskGroupName": "task-group-example",
- "count": 2,
- "minResource": {
- "memory": 1000000000,
- "vcore": 100
- },
- "replaced": 1,
- "timedout": 1
- }
- ],
- "hasReserved": false,
- "reservations": []
- },
- {
- "applicationID": "application-0002",
- "usedResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "maxUsedResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "pendingResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "partition": "default",
- "queueName": "root.default",
- "submissionTime": 1648754032076020293,
- "requests": [],
- "allocations": [
- {
- "allocationKey": "54e5d77b-f4c3-4607-8038-03c9499dd99d",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0002",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task0"
- },
- "requestTime": 1648754034098912461,
- "allocationTime": 1648754035973982920,
- "allocationDelay": 1875070459,
- "uuid": "08033f9a-4699-403c-9204-6333856b41bd",
- "allocationID": "08033f9a-4699-403c-9204-6333856b41bd-0",
- "resource": {
- "memory": 2000000000,
- "vcore": 2000
- },
- "priority": "0",
- "nodeId": "node-0001",
- "applicationId": "application-0002",
- "partition": "default",
- "placeholder": false,
- "placeholderUsed": false
- },
- {
- "allocationKey": "af3bd2f3-31c5-42dd-8f3f-c2298ebdec81",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0002",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task1"
- },
- "requestTime": 1648754034098912461,
- "allocationTime": 1648754035973982920,
- "allocationDelay": 1875070459,
- "uuid": "96beeb45-5ed2-4c19-9a83-2ac807637b3b",
- "allocationID": "96beeb45-5ed2-4c19-9a83-2ac807637b3b-0",
- "resource": {
- "memory": 2000000000,
- "vcore": 2000
- },
- "priority": "0",
- "nodeId": "node-0002",
- "applicationId": "application-0002",
- "partition": "default",
- "placeholder": false,
- "placeholderUsed": false
- }
- ],
- "applicationState": "Running",
- "user": "system:serviceaccount:kube-system:deployment-controller",
- "groups": [
- "system:serviceaccounts",
- "system:serviceaccounts:kube-system",
- "system:authenticated"
- ],
- "rejectedMessage": "",
- "stateLog": [
- {
- "time": 1648741409145224000,
- "applicationState": "Accepted"
- },
- {
- "time": 1648741409145509400,
- "applicationState": "Starting"
- },
- {
- "time": 1648741409147432100,
- "applicationState": "Running"
- }
- ],
- "placeholderData": [],
- "hasReserved": false,
- "reservations": []
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Application
-
-### Partition/Queue application
-
-Fetch an Application given a Partition, Queue(optional) and Application ID and displays general information about the application like used resources, queue name, submission time and allocations.
-
-**URL** : `/ws/v1/partition/{partitionName}/application/{appId}` or `/ws/v1/partition/{partitionName}/queue/{queueName}/application/{appId}`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Deprecated**:
-
-Field `uuid` has been deprecated, would be removed from below response in YUNIKORN 1.7.0 release. `AllocationID` has replaced `uuid`. Both `uuid` and `AllocationID` fields have the same value. `AllocationID` has extra suffix containing hyphen and counter (-0, -1 and so on) at the end.
-
-**Content example**
-
-```json
-{
- "applicationID": "application-0001",
- "usedResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "maxUsedResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "pendingResource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "partition": "default",
- "queueName": "root.default",
- "submissionTime": 1648754032076020293,
- "requests": [
- {
- "allocationKey": "f137fab6-3cfa-4536-93f7-bfff92689382",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0001",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task2"
- },
- "requestTime": 16487540320812345678,
- "resource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "pendingCount": 1,
- "priority": "0",
- "requiredNodeId": "",
- "applicationId": "application-0001",
- "partition": "default",
- "placeholder": false,
- "placeholderTimeout": 0,
- "taskGroupName": "",
- "allocationLog": [
- {
- "message": "node(s) didn't match Pod's node affinity, node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate",
- "lastOccurrence": 16487540320812346001,
- "count": 81
- },
- {
- "message": "node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, node(s) didn't match Pod's node affinity",
- "lastOccurrence": 16487540320812346002,
- "count": 504
- },
- {
- "message": "node(s) didn't match Pod's node affinity",
- "lastOccurrence": 16487540320812346003,
- "count": 1170
- }
- ]
- }
- ],
- "allocations": [
- {
- "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0001",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task0"
- },
- "requestTime": 1648754034098912461,
- "allocationTime": 1648754035973982920,
- "allocationDelay": 1875070459,
- "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
- "allocationID": "9af35d44-2d6f-40d1-b51d-758859e6b8a8-0",
- "resource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "priority": "0",
- "nodeId": "node-0001",
- "applicationId": "application-0001",
- "partition": "default",
- "placeholder": false,
- "placeholderUsed": true
- }
- ],
- "applicationState": "Running",
- "user": "system:serviceaccount:kube-system:deployment-controller",
- "groups": [
- "system:serviceaccounts",
- "system:serviceaccounts:kube-system",
- "system:authenticated"
- ],
- "rejectedMessage": "",
- "stateLog": [
- {
- "time": 1648741409145224000,
- "applicationState": "Accepted"
- },
- {
- "time": 1648741409145509400,
- "applicationState": "Starting"
- },
- {
- "time": 1648741409147432100,
- "applicationState": "Running"
- }
- ],
- "placeholderData": [
- {
- "taskGroupName": "task-group-example",
- "count": 2,
- "minResource": {
- "memory": 1000000000,
- "vcore": 100
- },
- "replaced": 1,
- "timedout": 1
- }
- ],
- "hasReserved": false,
- "reservations": []
-}
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## UsersTracker
-### Get users usage tracking information
-
-Fetch all users usage given a Partition and displays general information about the users managed by YuniKorn.
-
-**URL** : `/ws/v1/partition/{partitionName}/usage/users`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content example**
-
-```json
-[
- {
- "userName": "user1",
- "groups": {
- "app2": "tester"
- },
- "queues":
- {
- "queuePath": "root",
- "resourceUsage": {
- "memory": 12000000000,
- "vcore": 12000
- },
- "runningApplications": ["app1", "app2"],
- "children": [
- {
- "queuePath": "root.default",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": ["app1"],
- "children": []
- },
- {
- "queuePath": "root.test",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": [
- "app2"
- ],
- "children": []
- }]
- }
- },
- {
- "userName": "user2",
- "groups": {
- "app1": "tester"
- },
- "queues":
- {
- "queuePath": "root",
- "resourceUsage": {
- "memory": 11000000000,
- "vcore": 10000
- },
- "runningApplications": ["app1", "app2", "app3"],
- "children": [
- {
- "queuePath": "root.default",
- "resourceUsage": {
- "memory": 5000000000,
- "vcore": 5000
- },
- "runningApplications": ["app1"],
- "children": []
- },
- {
- "queuePath": "root.test",
- "resourceUsage": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "runningApplications": [
- "app3"
- ],
- "children": []
- }]
- }
- }
-]
-```
-
-### Error response
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## UserTracker
-### Get specific user usage tracking information
-Fetch specific user usage given a Partition and displays general information about the users managed by YuniKorn.
-
-**URL** : `/ws/v1/partition/{partitionName}/usage/user/{userName}`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content example**
-
-```json
-{
- "userName": "user1",
- "groups": {
- "app1": "tester"
- },
- "queues":
- {
- "queuePath": "root",
- "resourceUsage": {
- "memory": 12000000000,
- "vcore": 12000
- },
- "runningApplications": ["app1", "app2"],
- "children": [
- {
- "queuePath": "root.default",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": ["app1"],
- "children": []
- },
- {
- "queuePath": "root.test",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": [
- "app2"
- ],
- "children": []
- }]
- }
-}
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## GroupsTracker
-### Get groups usage tracking information
-Fetch all groups usage given a Partition and displays general information about the groups managed by YuniKorn.
-
-**URL** : `/ws/v1/partition/{partitionName}/usage/groups`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content example**
-
-```json
-[
- {
- "groupName": "group1",
- "applications": ["app1", "app2"],
- "queues":
- {
- "queuePath": "root",
- "resourceUsage": {
- "memory": 12000000000,
- "vcore": 12000
- },
- "runningApplications": ["app1", "app2"],
- "children": [
- {
- "queuePath": "root.default",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": ["app1"],
- "children": []
- },
- {
- "queuePath": "root.test",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": [
- "app2"
- ],
- "children": []
- }]
- }
- },
- {
- "groupName": "group2",
- "applications": ["app1", "app2", "app3"],
- "queues":
- {
- "queuePath": "root",
- "resourceUsage": {
- "memory": 11000000000,
- "vcore": 10000
- },
- "runningApplications": ["app1", "app2", "app3"],
- "children": [
- {
- "queuePath": "root.default",
- "resourceUsage": {
- "memory": 5000000000,
- "vcore": 5000
- },
- "runningApplications": ["app1"],
- "children": []
- },
- {
- "queuePath": "root.test",
- "resourceUsage": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "runningApplications": [
- "app3"
- ],
- "children": []
- }]
- }
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## GroupTracker
-### Get specific group usage tracking information
-
-Fetch specific group usage given a Partition and displays general information about the groups managed by YuniKorn.
-
-**URL** : `/ws/v1/partition/{partitionName}/usage/group/{groupName}`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content example**
-
-```json
-{
- "groupName": "group1",
- "applications": ["app1", "app2"],
- "queues":
- {
- "queuePath": "root",
- "resourceUsage": {
- "memory": 12000000000,
- "vcore": 12000
- },
- "runningApplications": ["app1", "app2"],
- "children": [
- {
- "queuePath": "root.default",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": ["app1"],
- "children": []
- },
- {
- "queuePath": "root.test",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": [
- "app2"
- ],
- "children": []
- }]
- }
-}
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Nodes
-
-### Partition nodes
-
-Fetch all Nodes associated with given Partition and displays general information about the nodes managed by YuniKorn.
-Node details include host and rack name, capacity, resources, utilization, and allocations.
-
-**URL** : `/ws/v1/partition/{partitionName}/nodes`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-Here you can see an example response from a 2-node cluster having 3 allocations.
-
-```json
-[
- {
- "nodeID": "node-0001",
- "hostName": "",
- "rackName": "",
- "attributes": {
- "beta.kubernetes.io/arch": "amd64",
- "beta.kubernetes.io/os": "linux",
- "kubernetes.io/arch": "amd64",
- "kubernetes.io/hostname": "node-0001",
- "kubernetes.io/os": "linux",
- "node-role.kubernetes.io/control-plane": "",
- "node-role.kubernetes.io/master": "",
- "node.kubernetes.io/exclude-from-external-load-balancers": "",
- "ready": "true",
- "si.io/hostname": "node-0001",
- "si.io/rackname": "/rack-default",
- "si/instance-type": "",
- "si/node-partition": "[mycluster]default"
- },
- "capacity": {
- "ephemeral-storage": 75850798569,
- "hugepages-1Gi": 0,
- "hugepages-2Mi": 0,
- "memory": 14577000000,
- "pods": 110,
- "vcore": 10000
- },
- "allocated": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "occupied": {
- "memory": 154000000,
- "vcore" :750
- },
- "available": {
- "ephemeral-storage": 75850798569,
- "hugepages-1Gi": 0,
- "hugepages-2Mi": 0,
- "memory": 6423000000,
- "pods": 110,
- "vcore": 1250
- },
- "utilized": {
- "memory": 3,
- "vcore": 13
- },
- "allocations": [
- {
- "allocationKey": "54e5d77b-f4c3-4607-8038-03c9499dd99d",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0001",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task0"
- },
- "requestTime": 1648754034098912461,
- "allocationTime": 1648754035973982920,
- "allocationDelay": 1875070459,
- "uuid": "08033f9a-4699-403c-9204-6333856b41bd",
- "allocationID": "08033f9a-4699-403c-9204-6333856b41bd-0",
- "resource": {
- "memory": 2000000000,
- "vcore": 2000
- },
- "priority": "0",
- "nodeId": "node-0001",
- "applicationId": "application-0001",
- "partition": "default",
- "placeholder": false,
- "placeholderUsed": false
- },
- {
- "allocationKey": "deb12221-6b56-4fe9-87db-ebfadce9aa20",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0002",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task0"
- },
- "requestTime": 1648754034098912461,
- "allocationTime": 1648754035973982920,
- "allocationDelay": 1875070459,
- "uuid": "9af35d44-2d6f-40d1-b51d-758859e6b8a8",
- "allocationID": "9af35d44-2d6f-40d1-b51d-758859e6b8a8-0",
- "resource": {
- "memory": 4000000000,
- "vcore": 4000
- },
- "priority": "0",
- "nodeId": "node-0001",
- "applicationId": "application-0002",
- "partition": "default",
- "placeholder": false,
- "placeholderUsed": false
- }
- ],
- "schedulable": true
- },
- {
- "nodeID": "node-0002",
- "hostName": "",
- "rackName": "",
- "attributes": {
- "beta.kubernetes.io/arch": "amd64",
- "beta.kubernetes.io/os": "linux",
- "kubernetes.io/arch": "amd64",
- "kubernetes.io/hostname": "node-0002",
- "kubernetes.io/os": "linux",
- "ready": "false",
- "si.io/hostname": "node-0002",
- "si.io/rackname": "/rack-default",
- "si/instance-type": "",
- "si/node-partition": "[mycluster]default"
- },
- "capacity": {
- "ephemeral-storage": 75850798569,
- "hugepages-1Gi": 0,
- "hugepages-2Mi": 0,
- "memory": 14577000000,
- "pods": 110,
- "vcore": 10000
- },
- "allocated": {
- "memory": 2000000000,
- "vcore": 2000
- },
- "occupied": {
- "memory": 154000000,
- "vcore" :750
- },
- "available": {
- "ephemeral-storage": 75850798569,
- "hugepages-1Gi": 0,
- "hugepages-2Mi": 0,
- "memory": 6423000000,
- "pods": 110,
- "vcore": 1250
- },
- "utilized": {
- "memory": 8,
- "vcore": 38
- },
- "allocations": [
- {
- "allocationKey": "af3bd2f3-31c5-42dd-8f3f-c2298ebdec81",
- "allocationTags": {
- "kubernetes.io/label/app": "sleep",
- "kubernetes.io/label/applicationId": "application-0001",
- "kubernetes.io/label/queue": "root.default",
- "kubernetes.io/meta/namespace": "default",
- "kubernetes.io/meta/podName": "task1"
- },
- "requestTime": 1648754034098912461,
- "allocationTime": 1648754035973982920,
- "allocationDelay": 1875070459,
- "uuid": "96beeb45-5ed2-4c19-9a83-2ac807637b3b",
- "allocationID": "96beeb45-5ed2-4c19-9a83-2ac807637b3b-0",
- "resource": {
- "memory": 2000000000,
- "vcore": 2000
- },
- "priority": "0",
- "nodeId": "node-0002",
- "applicationId": "application-0001",
- "partition": "default",
- "placeholder": false,
- "placeholderUsed": false
- }
- ],
- "schedulable": true,
- "isReserved": false,
- "reservations": []
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Node
-
-### Partition node
-
-Fetch a Node associated with given Partition and Node ID and displays general information about the node managed by YuniKorn.
-Node details include host and rack name, capacity, resources, utilization, and allocations.
-
-**URL** : `/ws/v1/partition/{partitionName}/node/{nodeId}`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```json
-{
- "nodeID":"node-0001",
- "hostName":"",
- "rackName":"",
- "capacity":{
- "ephemeral-storage":75850798569,
- "hugepages-1Gi":0,
- "hugepages-2Mi":0,
- "memory":14577000000,
- "pods":110,
- "vcore":10000
- },
- "allocated":{
- "memory":6000000000,
- "vcore":6000
- },
- "occupied":{
- "memory":154000000,
- "vcore":750
- },
- "available":{
- "ephemeral-storage":75850798569,
- "hugepages-1Gi":0,
- "hugepages-2Mi":0,
- "memory":6423000000,
- "pods":110,
- "vcore":1250
- },
- "utilized":{
- "memory":3,
- "vcore":13
- },
- "allocations":[
- {
- "allocationKey":"54e5d77b-f4c3-4607-8038-03c9499dd99d",
- "allocationTags":{
- "kubernetes.io/label/app":"sleep",
- "kubernetes.io/label/applicationId":"application-0001",
- "kubernetes.io/label/queue":"root.default",
- "kubernetes.io/meta/namespace":"default",
- "kubernetes.io/meta/podName":"task0"
- },
- "requestTime":1648754034098912461,
- "allocationTime":1648754035973982920,
- "allocationDelay":1875070459,
- "uuid":"08033f9a-4699-403c-9204-6333856b41bd",
- "allocationID":"08033f9a-4699-403c-9204-6333856b41bd-0",
- "resource":{
- "memory":2000000000,
- "vcore":2000
- },
- "priority":"0",
- "nodeId":"node-0001",
- "applicationId":"application-0001",
- "partition":"default",
- "placeholder":false,
- "placeholderUsed":false
- },
- {
- "allocationKey":"deb12221-6b56-4fe9-87db-ebfadce9aa20",
- "allocationTags":{
- "kubernetes.io/label/app":"sleep",
- "kubernetes.io/label/applicationId":"application-0002",
- "kubernetes.io/label/queue":"root.default",
- "kubernetes.io/meta/namespace":"default",
- "kubernetes.io/meta/podName":"task0"
- },
- "requestTime":1648754034098912461,
- "allocationTime":1648754035973982920,
- "allocationDelay":1875070459,
- "uuid":"9af35d44-2d6f-40d1-b51d-758859e6b8a8",
- "allocationID":"9af35d44-2d6f-40d1-b51d-758859e6b8a8-0",
- "resource":{
- "memory":4000000000,
- "vcore":4000
- },
- "priority":"0",
- "nodeId":"node-0001",
- "applicationId":"application-0002",
- "partition":"default",
- "placeholder":false,
- "placeholderUsed":false
- }
- ],
- "schedulable":true
-}
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Node utilization
-
-Show how every node is distributed with regard to dominant resource utilization.
-
-**Status** : Deprecated since v1.5.0 and will be removed in the next major release. Replaced with `/ws/v1/scheduler/node-utilizations`.
-
-**URL** : `/ws/v1/scheduler/node-utilization`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```json
-{
- "type": "vcore",
- "utilization": [
- {
- "bucketName": "0-10%",
- "numOfNodes": 1,
- "nodeNames": [
- "aethergpu"
- ]
- },
- {
- "bucketName": "10-20%",
- "numOfNodes": 2,
- "nodeNames": [
- "primary-node",
- "second-node"
- ]
- },
- ...
- ]
-}
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Node utilizations
-
-Show the nodes utilization of different types of resources in a cluster.
-
-**URL** : `/ws/v1/scheduler/node-utilizations`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```json
-[
- {
- "clusterId": "mycluster",
- "partition": "default",
- "utilizations": [
- {
- "type": "pods",
- "utilization": [
- {
- "bucketName": "0-10%",
- "numOfNodes": 2,
- "nodeNames": [
- "primary-node",
- "second-node"
- ]
- },
- {
- "bucketName": "10-20%"
- },
- ...
- ]
- },
- {
- "type": "vcores",
- "utilization": [
- {
- "bucketName": "0-10%",
- "numOfNodes": 2,
- "nodeNames": [
- "primary-node",
- "second-node"
- ]
- },
- {
- "bucketName": "10-20%"
- },
- ...
- ]
- },
- ...
- ]
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Goroutines info
-
-Dumps the stack traces of the currently running goroutines.
-
-**URL** : `/ws/v1/stack`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```text
-goroutine 356 [running
-]:
-github.com/apache/yunikorn-core/pkg/webservice.getStackInfo.func1(0x30a0060,
-0xc003e900e0,
-0x2)
- /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/handlers.go: 41 +0xab
-github.com/apache/yunikorn-core/pkg/webservice.getStackInfo(0x30a0060,
-0xc003e900e0,
-0xc00029ba00)
- /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/handlers.go: 48 +0x71
-net/http.HandlerFunc.ServeHTTP(0x2df0e10,
-0x30a0060,
-0xc003e900e0,
-0xc00029ba00)
- /usr/local/go/src/net/http/server.go: 1995 +0x52
-github.com/apache/yunikorn-core/pkg/webservice.Logger.func1(0x30a0060,
-0xc003e900e0,
-0xc00029ba00)
- /yunikorn/go/pkg/mod/github.com/apache/yunikorn-core@v0.0.0-20200717041747-f3e1c760c714/pkg/webservice/webservice.go: 65 +0xd4
-net/http.HandlerFunc.ServeHTTP(0xc00003a570,
-0x30a0060,
-0xc003e900e0,
-0xc00029ba00)
- /usr/local/go/src/net/http/server.go: 1995 +0x52
-github.com/gorilla/mux.(*Router).ServeHTTP(0xc00029cb40,
-0x30a0060,
-0xc003e900e0,
-0xc0063fee00)
- /yunikorn/go/pkg/mod/github.com/gorilla/mux@v1.7.3/mux.go: 212 +0x140
-net/http.serverHandler.ServeHTTP(0xc0000df520,
-0x30a0060,
-0xc003e900e0,
-0xc0063fee00)
- /usr/local/go/src/net/http/server.go: 2774 +0xcf
-net/http.(*conn).serve(0xc0000eab40,
-0x30a61a0,
-0xc003b74000)
- /usr/local/go/src/net/http/server.go: 1878 +0x812
-created by net/http.(*Server).Serve
- /usr/local/go/src/net/http/server.go: 2884 +0x4c5
-
-goroutine 1 [chan receive,
- 26 minutes
-]:
-main.main()
- /yunikorn/pkg/shim/main.go: 52 +0x67a
-
-goroutine 19 [syscall,
- 26 minutes
-]:
-os/signal.signal_recv(0x1096f91)
- /usr/local/go/src/runtime/sigqueue.go: 139 +0x9f
-os/signal.loop()
- /usr/local/go/src/os/signal/signal_unix.go: 23 +0x30
-created by os/signal.init.0
- /usr/local/go/src/os/signal/signal_unix.go: 29 +0x4f
-
-...
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Metrics
-
-Endpoint to retrieve metrics from the Prometheus server.
-The metrics are dumped with help messages and type information.
-
-**URL** : `/ws/v1/metrics`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```text
-# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
-# TYPE go_gc_duration_seconds summary
-go_gc_duration_seconds{quantile="0"} 2.567e-05
-go_gc_duration_seconds{quantile="0.25"} 3.5727e-05
-go_gc_duration_seconds{quantile="0.5"} 4.5144e-05
-go_gc_duration_seconds{quantile="0.75"} 6.0024e-05
-go_gc_duration_seconds{quantile="1"} 0.00022528
-go_gc_duration_seconds_sum 0.021561648
-go_gc_duration_seconds_count 436
-# HELP go_goroutines Number of goroutines that currently exist.
-# TYPE go_goroutines gauge
-go_goroutines 82
-# HELP go_info Information about the Go environment.
-# TYPE go_info gauge
-go_info{version="go1.12.17"} 1
-# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
-# TYPE go_memstats_alloc_bytes gauge
-go_memstats_alloc_bytes 9.6866248e+07
-
-...
-
-# HELP yunikorn_scheduler_vcore_nodes_usage Nodes resource usage, by resource name.
-# TYPE yunikorn_scheduler_vcore_nodes_usage gauge
-yunikorn_scheduler_vcore_nodes_usage{range="(10%, 20%]"} 0
-yunikorn_scheduler_vcore_nodes_usage{range="(20%,30%]"} 0
-yunikorn_scheduler_vcore_nodes_usage{range="(30%,40%]"} 0
-yunikorn_scheduler_vcore_nodes_usage{range="(40%,50%]"} 0
-yunikorn_scheduler_vcore_nodes_usage{range="(50%,60%]"} 0
-yunikorn_scheduler_vcore_nodes_usage{range="(60%,70%]"} 0
-yunikorn_scheduler_vcore_nodes_usage{range="(70%,80%]"} 1
-yunikorn_scheduler_vcore_nodes_usage{range="(80%,90%]"} 0
-yunikorn_scheduler_vcore_nodes_usage{range="(90%,100%]"} 0
-yunikorn_scheduler_vcore_nodes_usage{range="[0,10%]"} 0
-```
-
-## Configuration validation
-
-**URL** : `/ws/v1/validate-conf`
-
-**Method** : `POST`
-
-**Auth required** : NO
-
-### Success response
-
-Regardless whether the configuration is allowed or not if the server was able to process the request, it will yield a 200 HTTP status code.
-
-**Code** : `200 OK`
-
-#### Allowed configuration
-
-Sending the following simple configuration yields an accept
-
-```yaml
-partitions:
- - name: default
- queues:
- - name: root
- queues:
- - name: test
-```
-
-Reponse
-
-```json
-{
- "allowed": true,
- "reason": ""
-}
-```
-
-#### Disallowed configuration
-
-The following configuration is not allowed due to the "wrong_text" field put into the yaml file.
-
-```yaml
-partitions:
- - name: default
- queues:
- - name: root
- queues:
- - name: test
- - wrong_text
-```
-
-Reponse
-
-```json
-{
- "allowed": false,
- "reason": "yaml: unmarshal errors:\n line 7: cannot unmarshal !!str `wrong_text` into configs.PartitionConfig"
-}
-```
-
-## Configuration
-
-Endpoint to retrieve the current scheduler configuration
-
-**URL** : `/ws/v1/config`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content example (with `Accept: application/json` header)**
-
-```json
-{
- "Partitions": [
- {
- "Name": "default",
- "Queues": [
- {
- "Name": "root",
- "Parent": true,
- "Resources": {},
- "SubmitACL": "*",
- "ChildTemplate": {
- "Resources": {}
- }
- }
- ],
- "PlacementRules": [
- {
- "Name": "tag",
- "Create": true,
- "Filter": {
- "Type": ""
- },
- "Value": "namespace"
- }
- ],
- "Preemption": {
- "Enabled": false
- },
- "NodeSortPolicy": {
- "Type": ""
- }
- }
- ],
- "Checksum": "FD5D3726DF0F02416E02F3919D78F61B15D14425A34142D93B24C137ED056946",
- "Extra": {
- "event.trackingEnabled": "false",
- "log.core.scheduler.level": "info",
- "log.core.security.level": "info",
- "log.level": "debug"
- }
-}
-```
-
-**Content example (without `Accept: application/json` header)**
-
-```yaml
-partitions:
- - name: default
- queues:
- - name: root
- parent: true
- submitacl: "*"
- placementrules:
- - name: tag
- create: true
- value: namespace
-checksum: FD5D3726DF0F02416E02F3919D78F61B15D14425A34142D93B24C137ED056946
-extra:
- event.trackingEnabled: "false"
- log.core.scheduler.level: info
- log.core.security.level: info
- log.level: debug
-
-```
-
-## Application history
-
-Endpoint to retrieve historical data about the number of total applications by timestamp.
-
-**URL** : `/ws/v1/history/apps`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```json
-[
- {
- "timestamp": 1595939966153460000,
- "totalApplications": "1"
- },
- {
- "timestamp": 1595940026152892000,
- "totalApplications": "1"
- },
- {
- "timestamp": 1595940086153799000,
- "totalApplications": "2"
- },
- {
- "timestamp": 1595940146154497000,
- "totalApplications": "2"
- },
- {
- "timestamp": 1595940206155187000,
- "totalApplications": "2"
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-## Container history
-
-Endpoint to retrieve historical data about the number of total containers by timestamp.
-
-**URL** : `/ws/v1/history/containers`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```json
-[
- {
- "timestamp": 1595939966153460000,
- "totalContainers": "1"
- },
- {
- "timestamp": 1595940026152892000,
- "totalContainers": "1"
- },
- {
- "timestamp": 1595940086153799000,
- "totalContainers": "3"
- },
- {
- "timestamp": 1595940146154497000,
- "totalContainers": "3"
- },
- {
- "timestamp": 1595940206155187000,
- "totalContainers": "3"
- }
-]
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-**Content examples**
-
-```json
-{
- "status_code": 500,
- "message": "system error message. for example, json: invalid UTF-8 in string: ..",
- "description": "system error message. for example, json: invalid UTF-8 in string: .."
-}
-```
-
-
-## Endpoint healthcheck
-
-Endpoint to retrieve historical data about critical logs, negative resource on node/cluster/app, ...
-
-**URL** : `/ws/v1/scheduler/healthcheck`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```json
-{
- "Healthy": true,
- "HealthChecks": [
- {
- "Name": "Scheduling errors",
- "Succeeded": true,
- "Description": "Check for scheduling error entries in metrics",
- "DiagnosisMessage": "There were 0 scheduling errors logged in the metrics"
- },
- {
- "Name": "Failed nodes",
- "Succeeded": true,
- "Description": "Check for failed nodes entries in metrics",
- "DiagnosisMessage": "There were 0 failed nodes logged in the metrics"
- },
- {
- "Name": "Negative resources",
- "Succeeded": true,
- "Description": "Check for negative resources in the partitions",
- "DiagnosisMessage": "Partitions with negative resources: []"
- },
- {
- "Name": "Negative resources",
- "Succeeded": true,
- "Description": "Check for negative resources in the nodes",
- "DiagnosisMessage": "Nodes with negative resources: []"
- },
- {
- "Name": "Consistency of data",
- "Succeeded": true,
- "Description": "Check if a node's allocated resource <= total resource of the node",
- "DiagnosisMessage": "Nodes with inconsistent data: []"
- },
- {
- "Name": "Consistency of data",
- "Succeeded": true,
- "Description": "Check if total partition resource == sum of the node resources from the partition",
- "DiagnosisMessage": "Partitions with inconsistent data: []"
- },
- {
- "Name": "Consistency of data",
- "Succeeded": true,
- "Description": "Check if node total resource = allocated resource + occupied resource + available resource",
- "DiagnosisMessage": "Nodes with inconsistent data: []"
- },
- {
- "Name": "Consistency of data",
- "Succeeded": true,
- "Description": "Check if node capacity >= allocated resources on the node",
- "DiagnosisMessage": "Nodes with inconsistent data: []"
- },
- {
- "Name": "Reservation check",
- "Succeeded": true,
- "Description": "Check the reservation nr compared to the number of nodes",
- "DiagnosisMessage": "Reservation/node nr ratio: [0.000000]"
- }
- ]
-}
-```
-
-## Retrieve full state dump
-
-Endpoint to retrieve the following information in a single response:
-
-* Current timestamp (Unix timestamp in nanosecond)
-* List of partitions
-* List of applications (running, completed and rejected)
-* Application history
-* Nodes
-* Generic cluster information
-* Container history
-* Queues
-* RMDiagnostics
-* Log level
-* Configuration
-
-**URL** : `/ws/v1/fullstatedump`
-
-**Method** : `GET`
-
-**Auth required** : NO
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-The output of this REST query can be rather large, and it is a combination of those which have already been demonstrated.
-
-The `RMDiagnostics` shows the content of the K8Shim cache. The exact content is version dependent and has not stabilised.
-The current content shows the cached objects:
-* nodes
-* pods
-* priorityClasses
-* schedulingState (pod status)
-
-### Failure response
-
-**Code**: `500 Internal Server Error`
-
-## Batch Events
-
-Endpoint is used to retrieve a batch of event records.
-
-**URL**: `/ws/v1/events/batch`
-
-**METHOD** : `GET`
-
-**Auth required** : NO
-
-**URL query parameters** :
-- `count` (optional) : Specifies the maxmem number of events to be included in the response.
-- `start` (optional) : Specifies the starting ID for retrieving events. If the specified ID is outside the ring buffer
-(too low or too high), the response will include the lowest and highest ID values with `EventRecords` being empty.
-
-
-### Success response
-
-**Code**: `200 OK`
-
-**Content examples**
-
-```json
-{
- "InstanceUUID": "400046c6-2180-41a2-9be1-1c251ab2c498",
- "LowestID": 0,
- "HighestID": 7,
- "EventRecords": [
- {
- "type": 3,
- "objectID": "yk8s-worker",
- "message": "schedulable: true",
- "timestampNano": 1701347180239597300,
- "eventChangeType": 1,
- "eventChangeDetail": 302,
- "resource": {}
- },
- {
- "type": 3,
- "objectID": "yk8s-worker",
- "message": "Node added to the scheduler",
- "timestampNano": 1701347180239650600,
- "eventChangeType": 2,
- "resource": {
- "resources": {
- "ephemeral-storage": {
- "value": 502921060352
- },
- "hugepages-1Gi": {},
- "hugepages-2Mi": {},
- "memory": {
- "value": 33424998400
- },
- "pods": {
- "value": 110
- },
- "vcore": {
- "value": 8000
- }
- }
- }
- }
- ]
-}
-```
-
-### Error response
-
-**Code** : `500 Internal Server Error`
-
-### Event stream
-
-Creates a persistent HTTP connection for event streaming. New events are sent to the clients immediately, so unlike the batch interface, there is no need for polling.
-The number of active connections is limited. The default setting is 100 connections total and 15 connections per host. The respective configmap properties are `event.maxStreams` and `event.maxStreamsPerHost`.
-
-**URL**: `/ws/v1/events/stream`
-
-**METHOD** : `GET`
-
-**Auth required** : NO
-
-**URL query parameters**:
-- `count` (optional) : Specifies the number of past events (those which have been generated before the connection establishment) to include in the response. Default value is 0.
-
-### Success response
-
-**Code**: `200 OK`
-
-**Content examples**
-
-```json
-{"type":2,"objectID":"app-1","timestampNano":1708465452903045265,"eventChangeType":1,"eventChangeDetail":204,"resource":{}}
-{"type":2,"objectID":"app-1","timestampNano":1708465452903192898,"eventChangeType":2,"eventChangeDetail":201,"referenceID":"alloc-1","resource":{"resources":{"memory":{"value":10000000},"vcore":{"value":1000}}}}
-{"type":3,"objectID":"node-1:1234","timestampNano":1708465452903312146,"eventChangeType":2,"eventChangeDetail":303,"referenceID":"alloc-1","resource":{"resources":{"memory":{"value":10000000},"vcore":{"value":1000}}}}
-{"type":2,"objectID":"app-1","timestampNano":1708465452903474210,"eventChangeType":1,"eventChangeDetail":205,"resource":{}}
-{"type":5,"objectID":"testuser","timestampNano":1708465452903506166,"eventChangeType":2,"eventChangeDetail":603,"referenceID":"root.singleleaf","resource":{"resources":{"memory":{"value":10000000},"vcore":{"value":1000}}}}
-```
-
-### Error responses
-
-**Code** : `400 Bad Request` (URL query is invalid)
-**Code** : `503 Service Unavailable` (Too many active streaming connections)
-**Code** : `500 Internal Server Error`
diff --git a/versioned_docs/version-1.5.0/api/system.md b/versioned_docs/version-1.5.0/api/system.md
deleted file mode 100644
index 1d685ffa58..0000000000
--- a/versioned_docs/version-1.5.0/api/system.md
+++ /dev/null
@@ -1,225 +0,0 @@
----
-id: system
-title: System
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-These endpoints are for the [pprof](https://github.com/google/pprof) profiling tool.
-
-## pprof
-
-**URL** : `/debug/pprof/`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```text
-/debug/pprof/
-
-Types of profiles available:
-Count Profile
-273 allocs
-0 block
-0 cmdline
-78 goroutine
-273 heap
-0 mutex
-0 profile
-29 threadcreate
-0 trace
-full goroutine stack dump
-Profile Descriptions:
-
-allocs: A sampling of all past memory allocations
-block: Stack traces that led to blocking on synchronization primitives
-cmdline: The command line invocation of the current program
-goroutine: Stack traces of all current goroutines
-heap: A sampling of memory allocations of live objects. You can specify the gc GET parameter to run GC before taking the heap sample.
-mutex: Stack traces of holders of contended mutexes
-profile: CPU profile. You can specify the duration in the seconds GET parameter. After you get the profile file, use the go tool pprof command to investigate the profile.
-threadcreate: Stack traces that led to the creation of new OS threads
-trace: A trace of execution of the current program. You can specify the duration in the seconds GET parameter. After you get the trace file, use the go tool trace command to investigate the trace.
-```
-
-## Heap
-
-**URL** : `/debug/pprof/heap`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Thread create
-
-**URL** : `/debug/pprof/threadcreate`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Goroutine
-
-**URL** : `/debug/pprof/goroutine`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Allocations
-
-**URL** : `/debug/pprof/allocs`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Block
-
-**URL** : `/debug/pprof/block`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Mutex
-
-**URL** : `/debug/pprof/mutex`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Cmdline
-
-**URL** : `/debug/pprof/cmdline`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Profile
-
-**URL** : `/debug/pprof/profile`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Symbol
-
-**URL** : `/debug/pprof/symbol`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
-
-## Trace
-
-**URL** : `/debug/pprof/trace`
-
-**Method** : `GET`
-
-### Success response
-
-**Code** : `200 OK`
-
-**Content examples**
-
-```proto
-// binary data from proto
-```
diff --git a/versioned_docs/version-1.5.0/archived_design/k8shim.md b/versioned_docs/version-1.5.0/archived_design/k8shim.md
deleted file mode 100644
index 01f08db2d9..0000000000
--- a/versioned_docs/version-1.5.0/archived_design/k8shim.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-id: k8shim
-title: Kubernetes Shim Design
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-Github repo: https://github.com/apache/yunikorn-k8shim
-
-Please read the [architecture](../design/architecture.md) doc before reading this one, you will need to understand
-the 3 layer design of YuniKorn before getting to understand what is the Kubernetes shim.
-
-## The Kubernetes shim
-
-The YuniKorn Kubernetes shim is responsible for talking to Kubernetes, it is responsible for translating the Kubernetes
-cluster resources, and resource requests via scheduler interface and send them to the scheduler core.
-And when a scheduler decision is made, it is responsible for binding the pod to the specific node. All the communication
-between the shim and the scheduler core is through the scheduler-interface.
-
-## The admission controller
-
-The admission controller runs in a separate pod, it runs a
-[mutation webhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)
-and a [validation webhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook), where:
-
-1. The `mutation webhook` mutates pod spec by:
- - Adding `schedulerName: yunikorn`
- - By explicitly specifying the scheduler name, the pod will be scheduled by YuniKorn scheduler.
- - Adding `applicationId` label
- - When a label `applicationId` exists, reuse the given applicationId.
- - When a label `spark-app-selector` exists, reuse the given spark app ID.
- - Otherwise, assign a generated application ID for this pod, using convention: `yunikorn-<namespace>-autogen`. This is unique per namespace.
- - Adding `queue` label
- - When a label `queue` exists, reuse the given queue name. Note, if placement rule is enabled, values set in the label is ignored.
- - Otherwise, adds `queue: root.default`
- - Adding `disableStateAware` label
- - If pod was assigned a generated applicationId by the admission controller, also set `disableStateAware: true`. This causes the generated application
- to immediately transition from the `Starting` to `Running` state so that it will not block other applications.
-2. The `validation webhook` validates the configuration set in the configmap
- - This is used to prevent writing malformed configuration into the configmap.
- - The validation webhook calls scheduler [validation REST API](api/scheduler.md#configuration-validation) to validate configmap updates.
-
-### Admission controller deployment
-
-By default, the admission controller is deployed as part of the YuniKorn Helm chart installation. This can be disabled if necessary (though not recommended) by setting the Helm parameter `embedAdmissionController` to `false`.
-
-On startup, the admission controller performs a series of tasks to ensure that it is properly registered with Kubernetes:
-1. Loads a Kubernetes secret called `admission-controller-secrets`. This secret stores a pair of CA certificates which are used to sign the TLS server certificate used by the admission controller.
-2. If the secret cannot be found or either CA certificate is within 90 days of expiration, generates new certificate(s). If a certificate is expiring, a new one is generated with an expiration of 12 months in the future. If both certificates are missing or expiring, the second certificate is generated with an expiration of 6 months in the future. This ensures that both certificates do not expire at the same time, and that there is an overlap of trusted certificates.
-3. If the CA certificates were created or updated, writes the secrets back to Kubernetes.
-4. Generates an ephemeral TLS server certificate signed by the CA certificate with the latest expiration date.
-5. Validates, and if necessary, creates or updates the Kubernetes webhook configurations named `yunikorn-admission-controller-validations` and `yunikorn-admission-controller-mutations`. If the CA certificates have changed, the webhooks will also be updated. These webhooks allow the Kubernetes API server to connect to the admission controller service to perform configmap validations and pod mutations.
-6. Starts up the admission controller HTTPS server.
-
-Additionally, the admission controller also starts a background task to wait for CA certificates to expire. Once either certificate is expiring within the next 30 days, new CA and server certificates are generated, the webhook configurations are updated, and the HTTPS server is quickly restarted. This ensures that certificates rotate properly without downtime.
-
-In production clusters, it is recommended to deploy the admission controller with two replicas by setting the Helm parameter `admissionController.replicaCount` to `2`. This will ensure that at least one admission controller webhook is reachable by the Kubernetes API server at all times. In this configuration, the CA certificates and webhook configurations are shared between the instances.
diff --git a/versioned_docs/version-1.5.0/assets/application-state.png b/versioned_docs/version-1.5.0/assets/application-state.png
deleted file mode 100644
index 2af46e96e1..0000000000
Binary files a/versioned_docs/version-1.5.0/assets/application-state.png and /dev/null differ
diff --git a/versioned_docs/version-1.5.0/assets/dashboard_secret.png b/versioned_docs/version-1.5.0/assets/dashboard_secret.png
deleted file mode 100644
index 60b4f976ce..0000000000
Binary files a/versioned_docs/version-1.5.0/assets/dashboard_secret.png and /dev/null differ
diff --git a/versioned_docs/version-1.5.0/assets/dashboard_token_select.png b/versioned_docs/version-1.5.0/assets/dashboard_token_select.png
deleted file mode 100644
index 59173fdab9..0000000000
Binary files a/versioned_docs/version-1.5.0/assets/dashboard_token_select.png and /dev/null differ
diff --git a/versioned_docs/version-1.5.0/assets/grafana_dashboard.png b/versioned_docs/version-1.5.0/assets/grafana_dashboard.png
deleted file mode 100644
index b097ee3769..0000000000
Binary files a/versioned_docs/version-1.5.0/assets/grafana_dashboard.png and /dev/null differ
diff --git a/versioned_docs/version-1.5.0/assets/k8shim-application-state.png b/versioned_docs/version-1.5.0/assets/k8shim-application-state.png
deleted file mode 100644
index b1c3f7bdd2..0000000000
Binary files a/versioned_docs/version-1.5.0/assets/k8shim-application-state.png and /dev/null differ
diff --git a/versioned_docs/version-1.5.0/assets/k8shim-node-state.png b/versioned_docs/version-1.5.0/assets/k8shim-node-state.png
deleted file mode 100644
index 5d5db56a88..0000000000
Binary files a/versioned_docs/version-1.5.0/assets/k8shim-node-state.png and /dev/null differ
diff --git a/versioned_docs/version-1.5.0/assets/priority-tree.png b/versioned_docs/version-1.5.0/assets/priority-tree.png
deleted file mode 100644
index 7288db5ea5..0000000000
Binary files a/versioned_docs/version-1.5.0/assets/priority-tree.png and /dev/null differ
diff --git a/versioned_docs/version-1.5.0/assets/queue-resource-quotas.png b/versioned_docs/version-1.5.0/assets/queue-resource-quotas.png
deleted file mode 100644
index fb72138941..0000000000
Binary files a/versioned_docs/version-1.5.0/assets/queue-resource-quotas.png and /dev/null differ
diff --git a/versioned_docs/version-1.5.0/design/cache_removal.md b/versioned_docs/version-1.5.0/design/cache_removal.md
deleted file mode 100644
index 2312643305..0000000000
--- a/versioned_docs/version-1.5.0/design/cache_removal.md
+++ /dev/null
@@ -1,456 +0,0 @@
----
-id: cache_removal
-title: Scheduler cache removal design
----
-
-<!--
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- -->
-
-:::caution
-The Interface Message definitions described in this design doc has undergone major refactoring to reduce the complexity. [YUNIKORN-337](https://issues.apache.org/jira/browse/YUNIKORN-337) was committed and simplified the message communication between Core and Shim to greater extent.
-See [Simplifying Interface Messages and Breaking Shim build dependency on Core](interface_message_simplification.md) to know the updated message definitions.
-:::
-
-# Proposal to combine Cache and Scheduler's implementation in the core
-This document describes the current state of the scheduler and cache implementation.
-It describes the changes planned based on the analysis that was done of the current behaviour.
-
-## Goals
-The goal is to provide the same functionality before and after the change.
-- Unit tests before and after the merge must all pass.
-- Smoke tests defined in the core should all pass without major changes.
-- End-to-end tests that are part of the shim code must all pass without changes.
-
-:::info
- Major changes for smoke tests are defined as changes to the tests that alter use case and thus test flows. Some changes will be needed as checks made could rely on cache objects which have been removed.
-:::
-
-## Background
-The current Scheduler Core is build up around two major components to store the data: the cache and scheduler objects.
-The cache objects form the base for most data to be tracked.
-The Scheduler objects track specific in flight details and are build on top of a cache object.
-
-The communication between the two layers uses a-synchronous events and in some cases direct updates.
-A synchronous update between the scheduler and the cache does mean that there is a short period the scheduler is "out of sync" with the cache.
-This short period can have an impact on the scheduling decisions.
-One of which is logged as [YUNIKORN-169](https://issues.apache.org/jira/browse/YUNIKORN-169).
-
-A further point is the complexity that the two structure brings to the code.
-A distinct set of messages to communicate between the scheduler and the cache. A one-on-one mapping between the scheduler and cache objects shows that the distinction is probably more artificial than required.
-
-
----
-
-## Structure analysis
-### Objects
-The existing objects as per the code analysis.
-The overlap between the scheduler and the cache objects is shown by showing them at the same line.
-N/A means that there is no equivalent object in either the scheduler or cache.
-
-| Cache Object | Scheduler Object |
-| ------------------------------ | ------------------------------ |
-| ClusterInfo | ClusterSchedulingContext |
-| PartitionInfo | partitionSchedulingContext |
-| AllocationInfo | schedulingAllocation |
-| N/A | schedulingAllocationAsk |
-| N/A | reservation |
-| ApplicationInfo | SchedulingApplication |
-| applicationState | N/A |
-| NodeInfo | SchedulingNode |
-| QueueInfo | SchedulingQueue |
-| SchedulingObjectState | N/A |
-
-The `initializer` code that is part of the cache does not define a specific object.
-It contains a mixture of code defined at the package level and code that is part of the `ClusterInfo` object.
-
-### Events
-Events defined in the core have multiple origins and destinations.
-Some events are only internal for the core between the cache and scheduler.
-These events will be removed.
-
-| Event | Flow | Proposal |
-| ----------------------------------------- | --------------------- | -------- |
-| AllocationProposalBundleEvent | Scheduler -> Cache | Remove |
-| RejectedNewApplicationEvent | Scheduler -> Cache | Remove |
-| ReleaseAllocationsEvent | Scheduler -> Cache | Remove |
-| RemoveRMPartitionsEvent | Scheduler -> Cache | Remove |
-| RemovedApplicationEvent | Scheduler -> Cache | Remove |
-| SchedulerNodeEvent | Cache -> Scheduler | Remove |
-| SchedulerAllocationUpdatesEvent | Cache -> Scheduler | Remove |
-| SchedulerApplicationsUpdateEvent | Cache -> Scheduler | Remove |
-| SchedulerUpdatePartitionsConfigEvent | Cache -> Scheduler | Remove |
-| SchedulerDeletePartitionsConfigEvent | Cache -> Scheduler | Remove |
-| RMApplicationUpdateEvent (add/remove app) | Cache/Scheduler -> RM | Modify |
-| RMRejectedAllocationAskEvent | Cache/Scheduler -> RM | Modify |
-| RemoveRMPartitionsEvent | RM -> Scheduler | |
-| RMUpdateRequestEvent | RM -> Cache | Modify |
-| RegisterRMEvent | RM -> Cache | Modify |
-| ConfigUpdateRMEvent | RM -> Cache | Modify |
-| RMNewAllocationsEvent | Cache -> RM | Modify |
-| RMReleaseAllocationEvent | Cache -> RM | Modify |
-| RMNodeUpdateEvent | Cache -> RM | Modify |
-| | | |
-
-Events that are handled by the cache will need to be handled by the core code after the removal of the cache.
-Two events are handled by the cache and the scheduler.
-
-## Detailed flow analysis
-### Object existing in both cache and scheduler
-The current design is based on the fact that the cache object is the basis for all data storage.
-Each cache object must have a corresponding scheduler object.
-The contract in the core around the cache and scheduler objects was simple.
-If the object exists in both scheduler and cache the object will be added to cache triggering the creation of the corresponding scheduler object.
-Removing the object is always handled in reverse: first from the scheduler which will trigger the removal from the cache.
-An example would be the creation of an application triggered by the `RMUpdateRequestEvent` would be processed by the cache.
-Creating a `SchedulerApplicationsUpdateEvent` to create the corresponding application in the scheduler.
-
-When the application and object state were added they were added into the cache objects.
-The cache objects were considered the data store and thus also contain the state.
-There were no corresponding state objects in the scheduler.
-Maintaining two states for the same object is not possible.
-
-The other exceptions to that rule are two objects that were considered volatile and scheduler only.
-The `schedulingAllocationAsk` tracks outstanding requests for an application in the scheduler.
-The `reservation` tracks a temporary reservation of a node for an application and ask combination.
-
-### Operations to add/remove app
-The RM (shim) sends a complex `UpdateRequest` as defined in the scheduler interface.
-This message is wrapped by the RM proxy and forwarded to the cache for processing.
-The RM can request an application to be added or removed.
-
-**application add or delete**
-```
-1. RMProxy sends cacheevent.RMUpdateRequestEvent to cache
-2. cluster_info.processApplicationUpdateFromRMUpdate
- 2.1: Add new apps to the partition.
- 2.2: Send removed apps to scheduler (but not remove anything from cache)
-3. scheduler.processApplicationUpdateEvent
- 3.1: Add new apps to scheduler
- (when fails, send RejectedNewApplicationEvent to cache)
- No matter if failed or not, send RMApplicationUpdateEvent to RM.
- 3.2: Remove app from scheduler
- Send RemovedApplicationEvent to cache
-```
-
-### Operations to remove allocations and add or remove asks
-The RM (shim) sends a complex `UpdateRequest` as defined in the scheduler interface.
-This message is wrapped by the RM proxy and forwarded to the cache for processing.
-The RM can request an allocation to be removed.
-The RM can request an ask to be added or removed
-
-**allocation delete**
-This describes the allocation delete initiated by the RM only
-````
-1. RMProxy sends cacheevent.RMUpdateRequestEvent to cache
-2. cluster_info.processNewAndReleaseAllocationRequests
- 2.1: (by-pass): Send to scheduler via event SchedulerAllocationUpdatesEvent
-3. scheduler.processAllocationUpdateEvent
- 3.1: Update ReconcilePlugin
- 3.2: Send confirmation of the releases back to Cache via event ReleaseAllocationsEvent
-4. cluster_info.processAllocationReleases to process the confirmed release
-````
-
-**ask add**
-If the ask already exists this add is automatically converted into an update.
-```
-1. RMProxy sends cacheevent.RMUpdateRequestEvent to cache
-2. cluster_info.processNewAndReleaseAllocationRequests
- 2.1: Ask sanity check (such as existence of partition/app), rejections are send back to the RM via RMRejectedAllocationAskEvent
- 2.2: pass checked asks to scheduler via SchedulerAllocationUpdatesEvent
-3. scheduler.processAllocationUpdateEvent
- 3.1: Update scheduling application with the new or updated ask.
- 3.2: rejections are send back to the RM via RMRejectedAllocationAskEvent
- 3.3: accepted asks are not confirmed to RM or cache
-```
-
-**ask delete**
-```
-1. RMProxy sends cacheevent.RMUpdateRequestEvent to cache
-2. cluster_info.processNewAndReleaseAllocationRequests
- 2.1: (by-pass): Send to scheduler via event SchedulerAllocationUpdatesEvent
-3. scheduler.processAllocationReleaseByAllocationKey
- 3.1: Update scheduling application and remove the ask.
-```
-
-### Operations to add, update or remove nodes
-The RM (shim) sends a complex `UpdateRequest` as defined in the scheduler interface.
-This message is wrapped by the RM proxy and forwarded to the cache for processing.
-The RM can request a node to be added, updated or removed.
-
-**node add**
-```
-1. RMProxy sends cacheevent.RMUpdateRequestEvent to cache
-2. cluster_info.processNewSchedulableNodes
- 2.1: node sanity check (such as existence of partition/node)
- 2.2: Add new nodes to the partition.
- 2.3: notify scheduler of new node via SchedulerNodeEvent
-3. notify RM of node additions and rejections via RMNodeUpdateEvent
- 3.1: notify the scheduler of allocations to recover via SchedulerAllocationUpdatesEvent
-4. scheduler.processAllocationUpdateEvent
- 4.1: scheduler creates a new ask based on the Allocation to recover
- 4.2: recover the allocation on the new node using a special process
- 4.3: confirm the allocation in the scheduler, on failure update the cache with a ReleaseAllocationsEvent
-```
-
-**node update and removal**
-```
-1. RMProxy sends cacheevent.RMUpdateRequestEvent to cache
-2. cluster_info.processNodeActions
- 2.1: node sanity check (such as existence of partition/node)
- 2.2: Node info update (resource change)
- 2.2.1: update node in cache
- 2.2.2: notify scheduler of the node update via SchedulerNodeEvent
- 2.3: Node status update (not removal), update node status in cache only
- 2.4: Node removal
- 2.4.1: update node status and remove node from the cache
- 2.4.2: remove alloations and inform RM via RMReleaseAllocationEvent
- 2.4.3: notify scheduler of the node removal via SchedulerNodeEvent
-3. scheduler.processNodeEvent add/remove/update the node
-```
-
-### Operations to add, update or remove partitions
-**Add RM**
-```
-1. RMProxy sends commonevents.RemoveRMPartitionsEvent
- if RM is already registered
- 1.1: scheduler.removePartitionsBelongToRM
- 1.1.1: scheduler cleans up
- 1.1.2: scheduler sends commonevents.RemoveRMPartitionsEvent
- 1.2: cluster_info.processRemoveRMPartitionsEvent
- 1.2.1: cache cleans up
-2. RMProxy sends commonevents.RegisterRMEvent
-3. cluster_info.processRMRegistrationEvent
- 2.1: cache update internal partitions/queues accordingly.
- 2.2: cache sends to scheduler SchedulerUpdatePartitionsConfigEvent.
-3. scheduler.processUpdatePartitionConfigsEvent
- 3.1: Scheduler update partition/queue info accordingly.
-```
-
-**Update and Remove partition**
-Triggered by a configuration file update.
-```
-1. RMProxy sends commonevents.ConfigUpdateRMEvent
-2. cluster_info.processRMConfigUpdateEvent
- 2.1: cache update internal partitions/queues accordingly.
- 2.2: cache sends to scheduler SchedulerUpdatePartitionsConfigEvent.
- 2.3: cache marks partitions for deletion (not removed yet).
- 2.4: cache sends to scheduler SchedulerDeletePartitionsConfigEvent
-3. scheduler.processUpdatePartitionConfigsEvent
- 3.1: scheduler updates internal partitions/queues accordingly.
-4. scheduler.processDeletePartitionConfigsEvent
- 4.1: Scheduler set partitionManager.stop = true.
- 4.2: PartitionManager removes queues, applications, nodes async.
- This is the REAL CLEANUP including the cache
-```
-
-### Allocations
-Allocations are initiated by the scheduling process.
-The scheduler creates a SchedulingAllocation on the scheduler side which then gets wrapped in an AllocationProposal.
-The scheduler has checked resources etc already and marked the allocation as inflight.
-This description picks up at the point the allocation will be confirmed and finalised.
-
-**New allocation**
-```
-1. Scheduler wraps an SchedulingAllocation in an AllocationProposalBundleEvent
-2. cluster_info.processAllocationProposalEvent
- preemption case: release preempted allocations
- 2.1: release the allocation in the cache
- 2.2: inform the scheduler the allocation is released via SchedulerNodeEvent
- 2.3: inform the RM the allocation is released via RMReleaseAllocationEvent
- all cases: add the new allocation
- 2.4: add the new allocation to the cache
- 2.5: rejections are send back to the scheduler via SchedulerAllocationUpdatesEvent
- 2.6: inform the scheduler the allocation is added via SchedulerAllocationUpdatesEvent
- 2.7: inform the RM the allocation is added via RMNewAllocationsEvent
-3. scheduler.processAllocationUpdateEvent
- 3.1: confirmations are added to the scheduler and change from inflight to confirmed.
- On failure of processing a ReleaseAllocationsEvent is send to the cache *again* to clean up.
- This is part of the issue in [YUNIKORN-169]
- cluster_info.processAllocationReleases
- 3.2: rejections remove the inflight allocation from the scheduler.
-```
-
-## Current locking
-**Cluster Lock:**
-A cluster contains one or more Partition objects. A partition is a sub object of Cluster.
-Adding or Removing ANY Partition requires a write-lock of the cluster.
-Retrieving any object within the cluster will require iterating over the Partition list and thus a read-lock of the cluster
-
-**Partition Lock:**
-The partition object contains all links to Queue, Application or Node objects.
-Adding or Removing ANY Queue, Application or Node needs a write-lock of the partition.
-Retrieving any object within the partition will require a read-lock of the partition to prevent data races
-
-Examples of operation needing a write-lock
-- Allocation processing after scheduling, will change application, queue and node objects.
- Partition lock is required due to possible updates to reservations.
-- Update of Node Resource
- It not only affect node's available resource, it also affects the Partition's total allocatable Resource
-
-Example of operations that need a read-lock:
-- Retrieving any Queue, Application or Node needs a read-lock
- The object itself is not locked as part of the retrieval
-- Confirming an allocation after processing in the cache
- The partition is only locked for reading to allow retrieval of the objects that will be changed.
- The changes are made on the underlying objects.
-
-Example of operations that do not need any lock:
-- Scheduling
- Locks are taken on the specific objects when needed, no direct updates to the partition until the allocation is confirmed.
-
-**Queue lock:**
-A queue can track either applications (leaf type) or other queues (parent type).
-Resources are tracked for both types in the same way.
-
-Adding or removing an Application (leaf type), or a direct child queue (parent type) requires a write-lock of the queue.
-Updating tracked resources requires a write-lock.
-Changes are made recursively never locking more than 1 queue at a time.
-Updating any configuration property on the queue requires a write-lock.
-Retrieving any configuration value, or tracked resource, application or queue requires a read-lock.
-
-Examples of operation needing a write-lock
-- Adding an application to a leaf queue
-- Updating the reservations
-
-Examples of operation needing a read-lock
-- Retrieving an application from a leaf type queue
-- Retrieving the pending resources
-
-**Application lock:**
-An application tracks resources of different types, the allocations and outstanding requests.
-Updating any tracked resources, allocations or requests requires a write-lock.
-Retrieving any of those values requires a read-lock.
-
-Scheduling also requires a write-lock of the application.
-During scheduling the write-lock is held for the application.
-Locks will be taken on the node or queue that need to be accessed or updated.
-Examples of the locks taken on other objects are:
-- a read lock to access queue tracked resources
-- a write-lock to update the in progress allocations on the node
-
-Examples of operation needing a write-lock
-- Adding a new ask
-- Trying to schedule a pending request
-
-Examples of operation needing a read-lock
-- Retrieving the allocated resources
-- Retrieving the pending requests
-
-**Node lock:**
-An node tracks resources of different types and allocations.
-Updating any tracked resources or allocations requires a write-lock.
-Retrieving any of those values requires a read-lock.
-
-Checks run during the allocation phases take locks as required.
-Read-locks when checking write-locks when updating.
-A node is not locked for the whole allocation cycle.
-
-Examples of operation needing a write-lock
-- Adding a new allocation
-- updating the node resources
-
-Examples of operation needing a read-lock
-- Retrieving the allocated resources
-- Retrieving the reservation status
-
-## How to merge Cache and scheduler objects
-Since there is no longer the requirement to distinguish the objects in the cache and scheduler the `scheduling` and `info` parts of the name will be dropped.
-
-Overview of the main moves and merges:
-1. `application_info` & `scheduling_application`: **merge** to `scheduler.object.application`
-2. `allocation_info` & `scheduling_allocation`: **merge** to `scheduler.object.allocation`
-3. `node_info` & `scheduling_node`: **merge** to `scheduler.object.node`
-4. `queue_info` & `scheduling_queue`: **merge** to `scheduler.object.queue`
-5. `partition_info` & `scheduling_partition`: **merge** to `scheduler.PartitionContext`
-6. `cluster_info` & `scheduling_context`: **merge** to `scheduler.ClusterContext`
-7. `application_state`: **move** to `scheduler.object.applicationState`
-8. `object_state`: **move** to `scheduler.object.objectState`
-9. `initializer`: **merge** into `scheduler.ClusterContext`
-
-This move and merge of code includes a refactor of the objects into their own package.
-That thus affects the two scheduler only objects, reservations and schedulingAsk, that are already defined.
-Both will be moved into the objects package.
-
-The top level scheduler package remains for the contexts and scheduling code.
-
-## Code merges
-The first change is the event processing.
-All RM events will now directly be handled in the scheduler.
-Event handling will undergo a major change, far more than a simple merge.
-Only the RM generated events will be left after the merge.
-As described in the analysis above the scheduler is, in almost all cases, notified of changes from RM events.
-
-Broadly speaking there are only three types of changes triggered by the event removal:
-- configuration changes: new scheduler code required as the cache handling is not transferable to the scheduler
-- node, ask and application changes: merge of the cache code into the scheduler
-- allocation changes: removal of confirmation cycle and simplification of the scheduler code
-
-Part of the event handling is the processing of the configuration changes.
-All configuration changes will now update the scheduler objects directly.
-The way the scheduler works is slightly different from the cache which means the code is not transferable.
-
-Nodes and applications are really split between the cache and scheduler.
-Anything that is tracked in the cache object that does not have an equivalent value in the scheduler object will be moved into the scheduler object.
-All references to scheduler objects will be removed.
-With the code merges existing scheduler code that calls out directly into the cache objects will return the newly tracked value in the scheduler object.
-These calls will thus become locked calls in the scheduler.
-
-The concept of an in flight allocation will be removed.
-Allocation will be made in the same scheduling iteration without events or creation of a proposal.
-Removing the need for tracking of allocating resources on the scheduler objects.
-In flight resource tracking was required to make sure that an allocation while not confirmed by the cache would being taken into account while making scheduling decisions.
-
-The application and object state will be an integrated part of the scheduler object.
-A state change is thus immediate and this should prevent an issue like [YUNIKORN-169](https://issues.apache.org/jira/browse/YUNIKORN-169) from occuring.
-
-## Locking after merge
-
-### Direction of lock
-It is possible to acquire another lock while holding a lock, but we need to make sure that we do not allow:
-- Holding A.lock and acquire B's lock.
-- Holding B.lock and acquire B's lock.
-
-The current code in the scheduler takes a lock as late as possible and only for the time period needed.
-Some actions are not locked on the scheduler side just on the cache side as each object has its own lock.
-This means that a read of a value from the cache would not lock the scheduling object.
-
-With the integration of the cache into the scheduler the number of locks will decrease as the number of objects decreases.
-Each equivalent object, cache and scheduler, which used to have their own lock will now have just one.
-After the merge of the code is performed one lock will be left.
-Locking will occur more frequently as the number of fields in the scheduler objects has increased.
-
-Calls that did not lock the scheduler object before the merge will become locked.
-Lock contention could lead to performance degradation.
-The reduced overhead in objects and event handling can hopefully compensate for this.
-One point to keep track of is the change in locking behaviour.
-New behaviour could lead to new deadlock situations when code is simply merged without looking at the order.
-
-### Mitigations for deadlocks
-The locking inside the scheduler will be left as is.
-This means that the main scheduling logic will be taking and releasing locks as required on the objects.
-There are no long held read-locks or write-locks until the application is locked to schedule it.
-
-A major point of attention will need to be that no iterations of objects should be performed while holding on to a lock.
-For instance during scheduling while iterating over a queue's application we should not lock the queue.
-
-Another example would be that event processing in the partition should not lock the partition unneeded.
-The partition should be locked while retrieving for instance the node that needs updating and release the lock before it tries to lock the node itself.
-
-This approach fits in with the current locking approach and will keep the locking changes to a minimum.
-Testing, specifically end-to-end testing, should catch these deadlocks.
-There are no known tools that could be used to detect or describe lock order.
diff --git a/versioned_docs/version-1.5.0/design/config_v2.md b/versioned_docs/version-1.5.0/design/config_v2.md
deleted file mode 100644
index e943bf4895..0000000000
--- a/versioned_docs/version-1.5.0/design/config_v2.md
+++ /dev/null
@@ -1,346 +0,0 @@
----
-id: config_v2
-title: Configuration V2
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Introduction
-
-Over time the YuniKorn configuration has increased in complexity. The current
-configuration for YuniKorn is split over a number of different options, file
-and command line, and formats. There is a requirement now to define an overall
-configuration approach that can be used for all components.
-
-### Goals
-
-- Define a configuration format
-- Define an update and modification strategy
-- Provide consistency between configuration of YuniKorn components
-- Legacy migration strategy
-
-### Non-Goals
-
-- Redefine the queue configuration
-- Migration timeline for the old configuration options
-
-### References
-
-#### Implementation JIRA
-
-[YUNIKORN-1221](https://issues.apache.org/jira/browse/YUNIKORN-1221) - [Umbrella] Configuration V2
-
-#### Other relevant JIRAs
-
-- [YUNIKORN-455](https://issues.apache.org/jira/browse/YUNIKORN-455) - Make the core configurable
-- [YUNIKORN-1213](https://issues.apache.org/jira/browse/YUNIKORN-1213) - Background health checker needs to be configurable
-- [YUNIKORN-1335](https://issues.apache.org/jira/browse/YUNIKORN-1335) - Write yunikorn-web error logs to stderr
-
-### Services to cover
-
-- Scheduler (Standard) - K8Shim + Core
-- Scheduler (Plugin) - K8Shim + Core
-- Admission controller
-
-### Services excluded
-
- - Web UI (not needed after [YUNIKORN-1335](https://issues.apache.org/jira/browse/YUNIKORN-1335))
-
-## Configuration format
-
-Currently only Kubernetes is a supported deployment pattern. Future shims may
-need an alternative configuration syntax. To enable this, we will update the
-scheduler interface to support passing the core configuration (the content of
-the `queues.yaml` ConfigMap entry) to the core on startup and refresh. The
-existing config watcher functionality in the core will be removed and the shim
-will gain the responsibility for watching for ConfigMap changes. The shim
-actually already has this ability now, it is just not used.
-
-We will use two ConfigMaps to configure YuniKorn:
- - `yunikorn-defaults`
- - This will be a new ConfigMap written by Helm; it will contain only values
- explicitly configured by an administrator via Helm variables.
- - `yunikorn-configs`
- - This ConfigMap will contain overrides for yunikorn-defaults. It was
- previously a Helm hook in previous YuniKorn releases; it will no longer
- be managed by Helm and may be updated freely by third-party tools.
-
-The effective configuration will be the combination of both `yunikorn-defaults`
- and `yunikorn-configs`, with `yunikorn-configs` taking precedence.
-
-Neither ConfigMap (even the existing one) is required for proper functionality.
-In the case where a ConfigMap does not exist, we will use compiled-in defaults
-for all options. This enables bootstrapping in a variety of environments,
-including local development mode, as the ConfigMap need not exist to bring the
-scheduler components up. Future configuration options should be set via the
-ConfigMap exclusively.
-
-### Mutability of configuration values
-
-We should strive for hot-reload of all configuration values where possible.
-Where hot-reload is not implemented, this should be clearly documented. For the
-initial release, the core config and admission controller will be
-hot-reloadable but many items in the shim will likely not be. The shim was not
-designed to hot-reload anything so this will be a large future task. Some items
-may never be reloadable due to architectural limitations.
-
-### Update handling
-
-Given the security issues involved with updates, the default Kubernetes access
-control alone should be used for ConfigMap updates. We can still syntax-check
-the core side of the configuration in the admission controller as before.
-Partial updates are allowed as Kubernetes supports patching of ConfigMaps.
-
-### Legacy configuration handling
-
-Helm will be updated to render all existing legacy options into the
-`yunikorn-defaults` ConfigMap for easier transition to the new configuration
-format. Consequently, it is not necessary for YuniKorn components to parse the
-old environment and command-line arguments.
-
-### Environment variables
-
-All environment variables for all services will be removed, with the exception
-of:
-
- - `NAMESPACE`
- - Default value: `default`
- - Will be auto-populated from Helm and resolve to the pod's running
- namespace
- - Needed so that YuniKorn can determine what namespace it was launched in
- - Should only be provided explicitly at development time
- - `KUBECONFIG`
- - Default value: `$HOME/.kube/config`
- - Will be ignored if running inside Kubernetes; in-cluster configuration
- will be used in that case
- - Needed so that we can bootstrap to K8s and load the YuniKorn ConfigMap at
- runtime
- - Should only be provided explicitly at development time
-
-### Helm considerations
-
-All configuration options which have moved into the ConfigMap will be marked as
-deprecated in the Helm chart documentation. Their replacement is the more
-generic `yunikornDefaults` dictionary. If the legacy values are present but
-the associated `yunikornDefaults` entry is missing, the legacy configuration
-value will be used. This will allow users some time to migrate to the new
-configuration style. The legacy attributes will be removed in a future release.
-
-### Core Configuration
-
-The core scheduler configuration is loaded from the `queues.yaml` section of
-the ConfigMap, assuming `service.policyGroup` is set to the default value
-`queues`. If the policy group has been customized, core scheduler configuration
-will be read from `{service.policyGroup}.yaml`. This section is special as its
-contents are passed directly to the core for evaluation and update and is not
-read directly by the shim. The content of this section is unchanged from prior
-releases.
-
-## Appendix
-
-### Default ConfigMap
-
-If not present, the default ConfigMap will resolve to these defaults.
-Additionally, individual options will resolve to those listed here if not
-specified. Note that these values are subject to change in future releases.
-
- apiVersion: v1
- kind: ConfigMap
- metadata:
- name: yunikorn-configs
- data:
- service.clusterId: "mycluster"
- service.policyGroup: "queues"
- service.schedulingInterval: "1s"
- service.volumeBindTimeout: "10s"
- service.eventChannelCapacity: "1048576"
- service.dispatchTimeout: "5m"
- service.operatorPlugins: "general"
- service.disableGangScheduling: "false"
- service.enableConfigHotRefresh: "true"
- service.placeholderImage: "registry.k8s.io/pause:3.7"
- service.instanceTypeNodeLabelKey: "node.kubernetes.io/instance-type"
- health.checkInterval: "30s"
- log.level: "0"
- kubernetes.qps: "1000"
- kubernetes.burst: "1000"
- admissionController.webHook.amServiceName: "yunikorn-admission-controller-service"
- admissionController.webHook.schedulerServiceAddress: "yunikorn-service:9080"
- admissionController.filtering.processNamespaces: ""
- admissionController.filtering.bypassNamespaces: "^kube-system$"
- admissionController.filtering.labelNamespaces: ""
- admissionController.filtering.noLabelNamespaces: ""
- admissionController.accessControl.bypassAuth: "false"
- admissionController.accessControl.trustControllers: "true"
- admissionController.accessControl.systemUsers: "^system:serviceaccount:kube-system:"
- admissionController.accessControl.externalUsers: ""
- admissionController.accessControl.externalGroups: ""
- queues.yaml: |
- partitions:
- - name: default
- placementrules:
- - name: tag
- value: namespace
- create: true
- queues:
- - name: root
- submitacl: '*'`
-
-### Admission Controller Configuration
-
-#### Removed Environment Variables
- - `POLICY_GROUP`
- - Use ConfigMap: `service.policyGroup`
- - `ENABLE_CONFIG_HOT_REFRESH`
- - Use ConfigMap: `service.enableConfigHotRefresh`
- - `SCHEDULER_SERVICE_ADDRESS`
- - Use ConfigMap: `admissionController.webHook.schedulerServiceAddress`
- - `ADMISSION_CONTROLLER_SERVICE`
- - Use ConfigMap: `admissionController.webHook.amServiceName`
- - `ADMISSION_CONTROLLER_NAMESPACE`
- - Use Environment variable: `NAMESPACE`
- - `ADMISSION_CONTROLLER_PROCESS_NAMESPACES`
- - Use ConfigMap: `admissionController.filtering.processNamespaces`
- - `ADMISSION_CONTROLLER_BYPASS_NAMESPACES`
- - Use ConfigMap: `admissionController.filtering.bypassNamespaces`
- - `ADMISSON_CONTROLLER_LABEL_NAMESPACES`
- - Use ConfigMap: `admissionController.filtering.labelNamespaces`
- - `ADMISSION_CONTROLLER_NO_LABEL_NAMESPACES`
- - Use ConfigMap: `admissionController.filtering.noLabelNamespaces`
-
-#### Removed CLI Options
-None
-
-### Scheduler (Standard) Configuration
-
-#### Removed Environment Variables
- - `USER_LABEL_KEY`
- - No replacement
- - `OPERATOR_PLUGINS`
- - Use ConfigMap: `service.operatorPlugins`
- - `PLACEHOLDER_IMAGE`
- - Use ConfigMap: `service.placeholderImage`
-
-#### Removed CLI Options
- - `-clusterId`
- - Use ConfigMap: `service.clusterId`
- - `-clusterVersion`
- - No replacement
- - `-policyGroup`
- - Use ConfigMap: `service.policyGroup`
- - `-interval`
- - Use ConfigMap: `service.schedulingInterval`
- - `-logLevel`
- - Use ConfigMap: `log.level`
- - `-logEncoding`
- - No replacement
- - `-logFile`
- - No replacement
- - `-volumeBindTimeout`
- - Use ConfigMap: `service.volumeBindTimeout`
- - `-eventChannelCapacity`
- - Use ConfigMap: `service.eventChannelCapacity`
- - `-dispatchTimeout`
- - Use ConfigMap: `service.dispatchTimeout`
- - `-kubeQPS`
- - Use ConfigMap: `kubernetes.qps`
- - `-kubeBurst`
- - Use ConfigMap: `kubernetes.burst`
- - `-operatorPlugins`
- - Use ConfigMap: `service.operatorPlugins`
- - `-enableConfigHotRefresh`
- - Use ConfigMap: `service.enableConfigHotRefresh`
- - `-disableGangScheduling`
- - Use ConfigMap: `service.disableGangScheduling`
- - `-userLabelKey`
- - No replacement
- - `-placeHolderImage`
- Use ConfigMap: `service.placeholderImage`
-
-### Scheduler (Plugin) Configuration
-
-#### Removed Environment Variables
- - `USER_LABEL_KEY`
- - No replacement
- - `OPERATOR_PLUGINS`
- - Use ConfigMap: `service.operatorPlugins`
- - `PLACEHOLDER_IMAGE`
- - Use ConfigMap: `service.placeholderImage`
-
-#### Removed CLI Options
- - `--yk-scheduler-name`
- - No replacement
- - `--yk-cluster-id`
- - Use ConfigMap: `service.clusterId`
- - `--yk-cluster-version`
- - No replacement
- - `--yk-policy-group`
- - Use ConfigMap: `service.policyGroup`
- - `--yk-scheduling-interval
- - Use ConfigMap: `service.schedulingInterval`
- - `--yk-kube-config`
- - Use environment: `KUBECONFIG`
- - `--yk-log-level`
- - Use ConfigMap: `log.level`
- - `--yk-log-encoding`
- - No replacement
- - `--yk-log-file`
- - No replacement
- - `--yk-event-channel-capacity`
- - Use ConfigMap: `service.eventChannelCapacity`
- - `--yk-dispatcher-timeout`
- - Use ConfigMap: `service.dispatchTimeout`
- - `--yk-kube-qps`
- - Use ConfigMap: `kubernetes.qps`
- - `--yk-kube-burst`
- - Use ConfigMap: `kubernetes.burst`
- - `--yk-operator-plugins`
- - Use ConfigMap: `service.operatorPlugins`
- - `--yk-enable-config-hot-refresh`
- - Use ConfigMap: `service.enableConfigHotRefresh`
- - `--yk-disable-gang-scheduling`
- - Use ConfigMap: `service.disableGangScheduling`
- - `--yk-user-label-key`
- - No replacement
- - `--yk-placeholder-image`
- - Use ConfigMap: `service.placeholderImage`
-
-### Helm Configuration
-
-#### Removed Options
- - `userLabelKey`
- - No replacement
-
-#### Deprecated Options
- - `operatorPlugins`
- - Use ConfigMap: `service.operatorPlugins`
- - `placeHolderImage`
- - Use ConfigMap: `service.placeholderImage`
- - `admissionController.processNamespaces`
- - Use ConfigMap: `admissionController.filtering.processNamespaces`
- - `admissionController.bypassNamespaces`
- - Use ConfigMap: `admissionController.filtering.bypassNamespaces`
- - `admissionController.labelNamespaces`
- - Use ConfigMap: `admissionController.filtering.labelNamespaces`
- - `admissionController.noLabelNamespaces`
- - Use ConfigMap: `admissionController.filtering.noLabelNamespaces`
- - `configuration`
- - Use ConfigMap: `queues.yaml`
-
diff --git a/versioned_docs/version-1.5.0/design/historical_usage_tracking.md b/versioned_docs/version-1.5.0/design/historical_usage_tracking.md
deleted file mode 100644
index 83d068033c..0000000000
--- a/versioned_docs/version-1.5.0/design/historical_usage_tracking.md
+++ /dev/null
@@ -1,762 +0,0 @@
----
-id: historical_usage_tracking
-title: Historical Usage Tracking
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-
-## Introduction
-
-Tracking an application lifecycle is not easy in the current YuniKorn setup.
-Logs and statedump data is required to build an overview.
-Historical tracking of applications is only possible with limited detail per application.
-Applications come and go, we only track what is running and a time limited set of completed applications.
-
-Storing detailed tracking information in memory is problematic.
-Unbound growth can cause performance issues or even an out of memory failure of the service.
-The lessons learned from the YARN days have shown that it is not simple.
-
-A conscious choice was also made to keep YuniKorn stateless.
-The service does not maintain its own datastore for any of its operations.
-Adding a datastore for application and usage tracking will complicate things.
-
-Tracking data can be easily generated and made available for external consumption.
-The design will discuss the option to generate an event stream for applications, queues and nodes to allow external tools to build an overview of the usage pattern.
-
-Work to be tracked under [YUNIKORN-1628](https://issues.apache.org/jira/browse/YUNIKORN-1628)
-
-## Goals
-
-- Implementation of an event stream for an application, including:
- - State changes
- - Asks and allocation changes
-- Implementation of an event stream for a node, including:
- - State changes
- - Allocation changes
-- Implementation of an event stream for a queue, including:
- - State changes
- - Usage changes
-- Define a REST interface for event retrieval
-
-## Non Goals
-
-- Add a data store for the historical data
-- Display the event information
-- Rebuild data on recovery
- - Historical data will not be rebuild
-- Authentication and Authorisation on the REST interface
-
-## Existing Event System
-
-The event system was designed to be far more flexible than the current usage.
-Events for requests, applications, nodes and queues have been defined.
-Most of those are currently not used.
-The current event system is built on top of a generic event definition.
-The scheduler interface defines the event as:
-
-```go
-si.EventRecord {
- Type: recordType,
- ObjectID: String,
- GroupID: String,
- Reason: String,
- Message: String,
- TimestampNano: int64,
-}
-```
-
-Events definitions are used in the core and shim.
-The simplicity of the events will most likely not match the current requirements.
-
-As part of the standard scheduling cycle we track details at different levels.
-Prometheus' metrics are tracked for specific changes and updates.
-We also generate events, REQUEST events, that get passed back into the K8shim to attach to the Kubernetes pods.
-
-The current events that get passed back are for:
-
-- *Insufficient Queue Resources*: part of the allocation cycle. Called from: `Application.tryAllocate()`
-- *Placeholder Size Mismatch*: part of the placeholder replacement cycle. Called from: `Application.tryPlaceholderAllocate()`
-
-Both events are of the type REQUEST.
-The K8shim also implements processing of NODE events but there is no code that generates those types of events.
-The APPLICATION and QUEUE type events are not created or processed.
-
-The event system was added as part of [YUNIKORN-42](https://issues.apache.org/jira/browse/YUNIKORN-42).
-The jira contains a simple design document for the event system.
-It only was implemented for events that we could not at that point get in any other way: [design v2](https://docs.google.com/document/d/1aKfY6wnBPCyBl03UfmMHbTSpabAbfxtsHT2KzOgEOQs/edit).
-The original thought was a more generic event system.
-It would relate everything back to either a pod or the YuniKorn CRD and was focussed on diagnostics and troubleshooting in general: [design v1](https://docs.google.com/document/d/19iMkLJGVwTSq9OfV9p75wOobJXAxR_CRo4YzSRG_Pzw/edit#heading=h.worp3vfnqgtn).
-Linking it all back to a specific pod is The YuniKorn CRD is not used at this point in time.
-
-### Scheduler integration
-
-When the event system was designed the whole purpose was to allow out of band processing of the events from the scheduling cycle.
-The events are generated during the scheduling cycle and processed asynchronously in the event system.
-
-A channel is used for collecting the events during the scheduling cycle.
-The scheduler generates an event and adds it for processing to the channel.
-After the placement of the event on the channel the scheduler proceeds with the normal cycle.
-Processing of the events does not, and must not, block the scheduling cycle.
-
-This part of the event system must be maintained as it will guarantee the performance of the scheduler.
-
-### Event storage
-
-All events that have been sent to the channel are read from the channel and placed in a temporary store for publishing.
-The store is a simple map with the key of the *ObjectID*.
-
-Some of the assumptions in the event store however make it not directly usable for the purpose as described here.
-The main limitation is that there can only be one event in the channel per *ObjectID*.
-The newest one is kept, the older one is dropped when a new event comes in.
-This however does not mean the code already available with minor changes could be re-used for this purpose.
-
-### Publishing events
-
-The current event system uses a push system for event publishing.
-The event system allows the creation of multiple event publishers.
-There is no implementation or design for a pull system, like for instance a REST based interface.
-
-Currently, there is only an event publisher for a shim defined.
-This push system will send all the events that have been collected during the push interval to the shim.
-All events that are pushed will be removed from the store.
-This keeps the size of the store to a minimum.
-
-There is no filtering or post-processing of events implemented.
-Each event stored in the store is forwarded to the shim when the publisher runs.
-See limitations of the store mentioned above.
-In the earlier design a level filter was described.
-That level was never part of the follow-up design, not in the events and not in the processing.
-
-## Event System Updates
-
-The currently defined events are not a fit for the system we want and need.
-Since the events are only used between the core and the K8shim via the publisher we do not need to maintain backwards compatibility.
-Changes can be made to the messages as we do not currently expose the message to the outside.
-
-The *message* and *reason* fields are currently not properly used.
-The content of the two overlaps.
-The message in both cases contains the reason, in slightly different wording.
-We do not need both.
-
-### Event description
-
-We are also missing two fields to allow an extended usage for historical tracking: the *resource* and the *change type*.
-Based on that the new message that would allow using the event system for tracking historical change would be:
-
-```go
-si.EventRecord {
- Type: eventRecordType,
- ChangeType: eventChangeType,
- ChangeDetail: eventChangeDetail,
- TimestampNano: int64,
- ObjectID: String,
- ReferenceID: String,
- Resource: si.Resource,
- Message: String,
-}
-```
-
-The existing *GroupID* has been renamed to *ReferenceID*. The
-*ReferenceID* is the identification of the second object for the event.
-As an example that would be the Allocation UUID for a new allocation
-added to an application, request or node. For the queue that would be
-the application ID.
-
-Note that the order of the attributes in the final definition might be
-different as we do not reuse names and IDs in the messages.
-
-### Event types
-
-By keeping the event type for REQUESTS we can still fulfil the original
-design of YUNIKORN-42. The current enumeration for the *eventRecordType*
-would not change. Definition of the eventRecordType enumeration:
-
-```text
-UNKNOWN = 0
-REQUEST = 1
-APP = 2
-NODE = 3
-QUEUE = 4
-```
-
-### Change types
-
-The additional change type that is added allows us to track the type of
-change. Depending on the content of the other fields it provides the
-possibility to track all changes we need to track. Definition of the
-eventChangeType enumeration:
-
-```text
-NONE = 0
-SET = 1
-ADD = 2
-REMOVE = 3
-```
-
-### Change details
-
-Change detail provides more on the reason for the event. The change
-detail is an enumerated value linked to the event types.
-
-```text
-DETAILS_NONE = 0
-
-REQUEST_CANCEL = 100 // Request cancelled by the RM
-REQUEST_ALLOC = 101 // Request allocated
-REQUEST_TIMEOUT = 102 // Request cancelled due to timeout
-
-APP_ALLOC = 200 // Allocation changed
-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
-APP_FAILING = 209 // State change to failing
-APP_FAILED = 210 // State change to failed
-APP_RESUMING = 211; // State change to resuming
-APP_EXPIRED = 212; // State change to expired
-
-NODE_DECOMISSION = 300 // Node removal
-NODE_READY = 301 // Node ready state change
-NODE_SCHEDULABLE = 302 // Node schedulable state change (cordon)
-NODE_ALLOC = 303 // Allocation changed
-NODE_CAPACITY = 304 // Capacity changed
-NODE_OCCUPIED = 305 // Occupied resource changed
-NODE_RESERVATION = 306; // Reservation/unreservation occurred
-
-QUEUE_CONFIG = 400 // Managed queue update or removal
-QUEUE_DYNAMIC = 401 // Dynamic queue update or removal
-QUEUE_TYPE = 402 // Queue type change
-QUEUE_MAX = 403 // Max resource changed
-QUEUE_GUARANTEED = 404 // Guaranteed resource changed
-QUEUE_APP = 405 // Application changed
-QUEUE_ALLOC = 406 // Allocation changed
-ALLOC_CANCEL = 500 // Allocation cancelled by the RM
-ALLOC_PREEMPT = 501 // Allocation preempted by the core
-ALLOC_TIMEOUT = 502 // Allocation cancelled due to timeout
-ALLOC_REPLACED = 503 // Allocation replacement (placeholder)
-ALLOC_NODEREMOVED = 504 // Allocation cancelled, node removal
-```
-
-### Content definition
-
-The *eventRecordType* defines the object that the *ObjectID* points to.
-The content of the *ReferenceID* depends on two things:
-- Change type
-- Object type inferred by the *eventRecordType*
-
-For an object of type application it would not make sense to have the reference point to another application etc.
-At this point the following mapping for *ReferenceID* is assumed:
-
-| Event Type | Reference ID |
-|------------|----------------------------------|
-| REQUEST | ApplicationID |
-| APP | Allocation UUID or Request UUID |
-| NODE | Allocation UUID |
-| QUEUE | ApplicationID or Allocation UUID |
-
-If the *eventChangeType* Is NONE or SET the *ReferenceID* is always empty.
-The exception is for the REQUEST as in that case the change type NONE has an application ID set.
-This special case is used to implement the existing functionality of the event system: sending events to the shim.
-
-The APP record type supports Request IDs and Allocation UUIDs to be set in the *ReferenceID*.
-The type of ID that is referenced is defined by the *ChangeDetail*.
-
-The QUEUE record type supports application IDs and Allocation UUIDs to be set in the *ReferenceID*.
-Individual allocations are not tracked on the queue.
-However, we leave that option open for the event system at this point.
-
-For the QUEUE if *ReferenceID* and *Resource* are set, the ID points to an allocation.
-This can only happen if the *ChangeDetail* is set to QUEUE_ALLOC.
-
-If only the *ReferenceID* is set it points to an application.
-This can only happen if the *ChangeDetail* is set to QUEUE_APP.
-Both cases can use the same *eventChangeType*, add or remove an allocation or an application from a queue.
-
-The *Resource* that is part of any event would be the size of the resource for that change.
-The interpretation depends on the *eventChangeType*.
-For a SET it is the absolute value. For the ADD and REMOVE it is the positive delta on the existing tracked value.
-The *Resource* is always a positive value.
-
-## Event storage
-
-The storage of events needs to be updated to allow multiple events to be stored for an *ObjectID*.
-This is required as one object could trigger multiple events in a short time and all are important to track.
-This will require a change from a map based storage to a different store or a change in the key used for the map.
-
-The simplest solution might be a slice of pointers to events.
-The slice has a configurable, limited set of entries.
-The slice is accessed and maintained as a ring buffer.
-This will prevent an unlimited growth of the schedulers memory requirements.
-During the implementation a decision will be made which configuration, time; count or both, for limiting the size will be supported.
-
-Nil, or empty, events will not be added to the storage.
-However, no publisher must assume that while processing events retrieved from the buffer and needs to handle nil references.
-A location in the buffer could contain a nil pointer and must be skipped while iterating over the buffer.
-If a publisher gets a nil event pointer it must not crash and proceed as normal.
-
-The current design will use two stores: one for external retrieval and one for the shim events.
-A filter at the receiving end will be created.
-The shim events will then be processed as per the existing implementation.
-The new events will be stored and managed as per this design document in [SHIM events](#shim-events).
-
-### Publishing events
-
-Events are currently not post processed and all events are sent to the shim.
-With the newly added events the publishing needs to be split into two separate loops.
-
-#### SHIM events
-
-Current functionality will be supported as described above.
-Updates are required as the content of the events has changed.
-The same event type will be generated.
-The same processing mechanism will be used.
-
-As part of processing events REQUEST type events are special.
-The REQUEST type with the change type NONE has an application ID set and is only sent as an event to the shim.
-These events must not be made available by any other publishers and are stored in a separate ring buffer.
-After the event is sent to the shim the reference to the event in the buffer is cleared, replaced with a nil.
-
-#### REST
-
-The REST service that is currently running can be reused for exposing the events.
-Proposal is to add a new endpoint to the HTTP service.
-The REST endpoint servicing the event data should be a new end point.
-
-Based on the current REST api definition the data exposed in the following new endpoint will be added to expose the events:
-```text
-/ws/v1/events/batch
-```
-
-The design will not define a sophisticated interface for querying events, like filtering, grouping, etc.
-This is a deliberate decision.
-Such an API can encourage bad practices later on.
-That should be done in a separate application which fetches the events from YuniKorn and persists them in a permanent storage and offers a more feature rich REST/query interface.
-This would be similar to what already exists in Apache Hadoop like Job History Server or Application Timeline Service.
-
-As mentioned earlier in this document, such an application is not in the scope.
-
-The batch endpoint, by default, returns a limited number of events.
-The number of events to return can be specifically set via the query parameter *count*.
-If the requested *count* is larger than the available number of events all events are returned.
-
-```text
-/ws/v1/events/batch?count=100
-```
-
-To prevent a DOS attack the maximum value of *count* might be limited as part of the implementation.
-
-The second query parameter that will be supported is *start*.
-This specifies the start ID of the first event returned.
-Every event is assigned a unique id starting from 0.
-The ring buffer maintains the current available highest and lowest ID.
-If *start* refers to an ID which doesn't exist in the buffer, then an empty response is returned from the server, with *LowestID* and *HighestID* properly filled:
-```json lines
-{
- "InstanceUUID": "b4751b7d-a1a3-4431-bb68-bff896adb9c2",
- "LowestID": 1100,
- "HighestID": 11000,
- "EventRecords": null
-}
-```
-
-In the next request, start should be defined as 1100.
-
-In the response, the *InstanceUUID* field shows the unique instance ID.
-Since YuniKorn is stateless, the generated ID for an event is not saved anywhere.
-If an event consumer saves the events to a backend database, it makes it possible to distinguish between events with the same ID.
-Also, clients can easily detect that YuniKorn was restarted.
-
-#### Streaming
-
-Streaming allows the user to see a continuous stream of events as they are occurring.
-This can be very useful if we want to trace the state changes inside YuniKorn for a longer amount of time.
-The REST interface can return the last "n" amount of events that occurred in a certain timeframe, but it will always be limited.
-We can only increase the number of events at the expense of memory usage, which might not be acceptable in certain environments.
-
-Although streaming is a nice feature, we do not consider it as a "must have", at least not in the first version of the history tracking.
-This is because it's more complicated in nature: it maintains an open HTTP connection towards the client which makes it stateful.
-There are ordering and memory usage concerns&considerations.
-We need to make sure that rogue clients cannot abuse it.
-Therefore, the first release of history tracking focuses on the batch interface.
-
-Streaming needs to coexist beside the current REST api.
-A separate endpoint must be exposed for the event stream:
-```text
-/ws/v1/events/stream
-```
-
-Streaming can be similar to how it's implemented inside Kubernetes informers.
-The API server keeps the connection alive and sends the necessary events about pods, nodes, configmaps, etc.
-The incoming data stream is decoded by the listeners.
-Event processing on the client side is not part of this design.
-
-At this point we do not provide endpoints for consumers to stream a specific event type as defined in [Event types](#event-types).
-This could be made available via separate endpoints in the future following the same design as for *batch* specification
-
-The *stream* endpoint does not take any query parameters.
-The consumer must allow for more than one (1) event to be sent in one response.
-No information besides the events will be sent in the response.
-
-As an example below the approximate output for the stream endpoint for two events
-
-```json
-[
- {
- "type": 2,
- "changeType": 1,
- "changeDetail": 203,
- "timestamp": 1649167576110750000,
- "objectID": "spark-app-1"
- },
- {
- "type": 4,
- "changeType": 2,
- "changeDetail": 405,
- "timestamp": 1649167576110754000,
- "objectID": "root.spark",
- "referenceID": "spark-app-1"
- }
-]
-```
-
-## Event overview
-
-### Generic events
-
-The following events are generated for streaming and REST consumers, meaning that they will not be sent to the shim.
-This is based on the description of the [Event System Updates](#event-system-updates) earlier in this document.
-It serves as a reference for the core scheduler actions that will trigger the event.
-
-| Event type | Change type | Change details | Reference type | Notes |
-|------------|-------------|-------------------|----------------|--------------------------------------------------|
-| APP | ADD | DETAILS_NONE | | New application added |
-| APP | ADD | APP_ALLOC | AllocationID | Successful allocation |
-| APP | ADD | APP_REQUEST | RequestID | Incoming resource request (pod) |
-| APP | REMOVE | DETAILS_NONE | | Normal removal of application |
-| APP | REMOVE | APP_REJECT | | Application rejected |
-| APP | REMOVE | ALLOC_CANCEL | AllocationID | Normal removal requested by the shim |
-| APP | REMOVE | ALLOC_TIMEOUT | AllocationID | Timeout |
-| APP | REMOVE | ALLOC_REPLACED | AllocationID | Replacement (placeholder) |
-| APP | REMOVE | ALLOC_PREEMPT | AllocationID | Preemption triggered |
-| APP | REMOVE | ALLOC_NODEREMOVED | AllocationID | Removal triggered by node removal |
-| APP | REMOVE | APP_REQUEST | RequestID | Normal removal requested by the shim |
-| APP | REMOVE | REQUEST_TIMEOUT | RequestID | Timeout (placeholder) |
-| 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 |
-| APP | SET | APP_FAILING | | State change: Failing |
-| APP | SET | APP_FAILED | | State change: Failed |
-| APP | SET | APP_RESUMING | | State change: Resuming |
-| APP | SET | APP_EXPIRED | | State change: Expired |
-| | | | | |
-| NODE | ADD | DETAILS_NONE | | New node added to the cluster |
-| NODE | ADD | NODE_ALLOC | AllocationID | Successful allocation |
-| NODE | REMOVE | NODE_DECOMISSION | | Removal requested by the shim |
-| NODE | REMOVE | NODE_ALLOC | AllocationID | Normal allocation removal requested by the shim |
-| NODE | SET | NODE_READY | | Update "ready" status |
-| NODE | SET | NODE_SCHEDULABLE | | Update "schedulable" status |
-| NODE | SET | NODE_CAPACITY | | Update node capacity |
-| NODE | SET | NODE_OCCUPIED | | Update occupied resources |
-| NODE | ADD | NODE_RESERVATION | | Add reservation to a node |
-| NODE | REMOVE | NODE_RESERVATION | | Remove reservation from a node |
-| | | | | |
-| QUEUE | ADD | DETAILS_NONE | | Adding new configured queue |
-| QUEUE | ADD | QUEUE_DYNAMIC | | Adding new dynamic queue |
-| QUEUE | ADD | QUEUE_APP | ApplicationID | Application added |
-| QUEUE | REMOVE | DETAILS_NONE | | Removing configured queue |
-| QUEUE | REMOVE | QUEUE_DYNAMIC | | Removing dynamic queue |
-| QUEUE | REMOVE | QUEUE_APP | ApplicationID | Application removed |
-| QUEUE | SET | QUEUE_MAX | | Max resource changed |
-| QUEUE | SET | QUEUE_GUARANTEED | | Guaranteed resource changed |
-| QUEUE | SET | QUEUE_TYPE | | Queue type change(parent/leaf) |
-
-### Shim events
-
-Shim events are a type of REQUEST and the application ID is set.
-Right now we send only two types of events to the shim, both of which are originated from the application:
-
-- Insufficient resources in the queue for a request
-- Real allocation is larger than placeholder
-
-| Event type | Change type | Change details | Reference type | Notes |
-|------------|-------------|----------------|----------------|-----------------------|
-| REQUEST | NONE | DETAILS_NONE | ApplicationID | New application added |
-| REQUEST | NONE | DETAILS_NONE | ApplicationID | Successful allocation |
-
-## Configuration
-
-As part of the design we anticipate the following configuration to be added for the event storage and retrieval.
-All settings will have the shared prefix: *service.event*.
-All the mentioned settings will require a restart of the scheduler for updates to take effect.
-
-The following settings will be added to the system:
-
-A flag to enable or disable sending request events to the K8shim.
-This externalises the current setting that needs a recompile of the code.
-The default mirrors the current default in the code.
-
-- Name: **requestEventsEnabled**
-- Allowed values: all boolean values will be converted into a boolean using ParseBool as defined in the `strconv` package[^1].
-- Default value: false
-
-A flag to enable or disable event collection in the system.
-The default is enabled for the tracking events.
-
-- Name: **trackingEventsEnabled**
-- Allowed values: all boolean values will be converted into a boolean using ParseBool as defined in the `strconv` package.
-- Default value: true
-
-Size of the store for events that will be sent to the shim, request events.
-Note that setting a size of 0 effectively turns off the request event system.
-
-- Name: **requestStoreCapacity**
-- Allowed values: integer value that can be converted into a 32-bit integer using ParseUint as defined in the `strconv` package[^2].
-- Default value: 1,000
-
-The number of events to store in the ring buffer.
-This number defines the size of the ring buffer and thus the memory impact the event storage will have on the scheduler.
-Note that setting a size of 0 effectively turns off the event collection system.
-
-- Name: **ringBufferCapacity**
-- Allowed values: integer value that can be converted into a 32-bit integer using ParseUint as defined in the `strconv` package
-- Default value: 100,000
-
-The maximum number of events to return in one REST response.
-The maximum that could be returned is limited to the ring buffer capacity.
-However, preparing a large response the size of the whole ring buffer could cause large peaks in the schedulers memory usage.
-This setting should be used to prevent these peaks.
-
-- Name: **RESTResponseSize**
-- Allowed values: integer value that can be converted into a 32-bit integer using ParseUint as defined in the `strconv` package
-- Default value: 10,000
-
-## Performance considerations
-
-### Memory usage of historical elements
-
-We need to estimate how many elements we can expect to be generated with different pod churn rates on a daily basis.
-Queue and node events are much rarer, so they are not accounted for.
-We also ignore potential failures and scheduling errors.
-
-An application undergoes state transitions, so the following events are generated:
-- Add new application
-- State change: New
-- State change: Accepted
-- State change: Starting
-- State change: Running
-- State change: Completing
-- State change: Completed
-- Allocation changed
-
-Pod (request) events:
-- Incoming allocation request
-- Successful allocation on a node
-
-Pod (request) events with gang scheduling:
-- Incoming resource request
-- Successful allocation on a node
-- Replace event for placeholder
-
-| Number of pods | Number of apps | Pods per app | Job type | Events per app | Events per pod | ∑ apps | ∑ pods | ∑ events |
-|----------------|----------------|--------------|----------|----------------|----------------|-------------------|-----------------|----------|
-| 150k | 1500 | 100 | normal | 200 + 7 | 2 | 310k (1500 * 207) | 300k (2 * 150k) | 610k |
-| 150k | 1500 | 100 | gang | 300 + 7 | 3 | 460k (1500 * 307) | 450k (3 * 150k) | 910k |
-| 300k | 3000 | 100 | normal | 200 + 7 | 2 | 621k (3000 * 207) | 600k (2 * 300k) | 1,2M |
-| 300k | 3000 | 100 | gang | 300 + 7 | 3 | 921k (3000 * 307) | 900k (3 * 300k) | 1,8M |
-
-On a busy cluster with 150,000 - 300,000 pods per day, we can expect the number of events generated to be around 600k - 1,8M (depending on the scheduling style).
-
-If we want to retain the events for 5 days, we need to store 9 million events in the worst case and 3 million in the best case.
-
-With 9 million objects in the memory, it is also critical to estimate how much extra memory usage is expected from YuniKorn with different kinds of data structures:
-
-- slice of pointers to si.EventRecord objects `[]*si.EventRecord`
-- slice of si.EventRecord objects `[]si.EventRecord`
-- slice of a memory-optimised data type `[]internalRecord`
-
-As the name suggests, internalRecord type would only be available inside the ring buffer.
-It's used together with string interning to save memory caused by repeated strings like IDs (application ID, ask ID, allocation ID, etc.).
-There are various interning libraries in Go, but removing elements is not possible from them.
-We need to create our own, so we can track the number of references per string.
-
-The following table summarizes memory usage and GC time, depending on how we store the events.
-The test was executed multiple times to get averages and ranges.
-The slice was created once, then an index variable was increased for each record, so the built-in `append()` function was not used.
-
-The results clearly indicate two things:
-
-- having millions of pointers has negative performance on both the memory usage and GC load
-- batch workloads inherently have a lot of repeated strings, so interning makes a noticeable difference
-
-The GC detects pointers, since it has to follow them to walk the object graph to identify unreferenced objects.
-If elements in the slice are pointers, then those allocations are scattered all around the heap (bad locality) with header information added by the allocator.
-This reduces memory access times and increases the amount of the data that is allocated.
-
-In the test, the assumption was 100 pods per application.
-In real life, this value might be different, most likely it's lower.
-The lower the value, the smaller the advantage of the interning - on the extreme, every application consists of only one pod.
-But even with only 30 pods per application, it has value - more modest, 20-30% reductions are not negligible when storing millions of elements.
-
-| Object type | Number of elements | Increased memory usage\* | GC time\*\* |
-|-------------------|--------------------|--------------------------|-------------|
-| []*si.EventRecord | 3M | 805 MiB | 85-105 ms |
-| []si.EventRecord | 3M | 437 MiB | 41-55 ms |
-| []internalRecord | 3M | 211 MiB | 5-16 ms |
-| []*si.EventRecord | 6M | 1595 MiB | 160-200 ms |
-| []si.EventRecord | 6M | 856 MiB | 75-110 ms |
-| []internalRecord | 6M | 404 MiB | 10-30 ms |
-| []*si.EventRecord | 9M | 2380 MiB | 270-320 ms |
-| []si.EventRecord | 9M | 1280 MiB | 116-150 ms |
-| []internalRecord | 9M | 593 MiB | 16-33 ms |
-
-*\* "Sys" metrics returned by the Go runtime*
-
-*\*\* measured by the execution time of `runtime.GC()`*
-
-### Handling slow and rogue clients during streaming
-
-It's possible to overwhelm YuniKorn with streaming or execute a DoS attack.
-
-The first thing we need to address is a rogue client which simply stops reading on the receiver side from the TCP socket.
-Eventually writes will block in YuniKorn.
-If we use channels and per-client goroutines, this should not be an issue - we can always check if the buffer is full using the built-in len() function.
-If this happens, we can just drop the connection.
-In some situations, the buffer is expected to be full, for example, when sending history.
-It's always faster to send out a lot of existing objects, so we can expect the buffer to get full at times.
-This can be solved by repeatedly checking the rate of writes - if it falls below a certain threshold, then again, we just drop the connection with an error message.
-
-We can also limit the number of concurrent streaming connections and historical objects to send, e.g. we simply won't serve requests which would result in sending millions of elements.
-
-Note that it's still possible to deny the service from legitimate users because YuniKorn lacks authentication on the REST interface.
-This will be solved in the future.
-
-### Approaches to streaming
-
-When a client requests a stream of events, it can define how many past events it wants to receive.
-This is necessary because when YuniKorn starts up, it's not possible to connect immediately.
-It can be important for certain users to save the state of YuniKorn on an external storage completely from the start.
-
-Sending the historical events must be separated from the new events that are constantly occurring in the system, that is, old and current events must not interleave.
-For example: we want a stream of old and new events, this means:
-
-- We're currently at *event~n~*
-- Send out events from *event~0~* all the way up to *event~n~*
-- In the meantime, *k* number of events have been generated
-- Therefore, send events up to event*~n+k~* until we're caught up completely
-
-#### **Send history first, then stream new events**
-
-The first approach is to retrieve the objects from the ring buffer and start to send them on a channel to the receiver.
-There is a separate buffered channel for new events with capacity *localBufferSize*.
-As soon as we finish sending the history, we switch to this channel and relay events from it towards the client.
-
-We can express this with the following pseudocode:
-```go
-consumerEventLoop(elementCount) {
- local = initLocalEventChannel(localBufferSize)
- // send history
- history := ringbuffer.getHistory(elementCount)
- foreach h : history {
- receiver <- h
- }
- // bridge new events
- foreach e : <-local {
- receiver <- e
- }
-}
-```
-
-The publisher logic is:
-```go
-publishEvent(event) {
- foreach c : localChannels {
- if len(c) == localBufferSize { // local buffer full?
- closeChan(receiver)
- closeChan(local)
- receiverId = getReceiver(c)
- abort("slow receiver: " + receiverId)
- }
- c <- event
- }
-}
-```
-
-Each receiver has its own goroutine.
-That is, 10 clients means 10 different `consumerEventLoop()` calls running on separate goroutines.
-
-To detect slow clients, we simply check the value of `len(c)` whenever we submit the new event.
-If this equals the capacity of the buffer, we drop the receiver and close the connection.
-
-It is possible to send events directly to the receiver channel and skip `c` on the publisher side which is local inside consumerEventLoop.
-This requires a simple state machine and a temporary slice of new events, since we are not allowed to send directly as long as the history is being transmitted.
-Overall, this is more complicated than the one described above.
-
-The simplicity of this method is notable, which is the main advantage: reasoning about its correctness is trivial.
-We do not need complicated test code and back-and-forth review cycles to ensure that it indeed results in the correct order of events.
-
-The biggest question is what happens if channel local becomes full.
-Let's say that localBufferSize is 1000.
-On a busy cluster with 100 events / second (busiest period), it takes 10 seconds to fill it up completely.
-However, nothing stops us from setting the capacity of the buffer to a higher value.
-If we bump it up to 10000, the client is expected to read the history in 100 seconds.
-On a decent network, this amount of time should be enough to read the event history, even if it means 100 000 entries from the ring buffer.
-If a single si.EventRecord results in 300 bytes of JSON text, then it is around 30MiB of data.
-Even if we take serialisation into account, this will not (can not) take minutes.
-
-The biggest disadvantage of this method is when a user requests a lot of elements from the history.
-For example, someone wants to retrieve the last 1M elements.
-In this case, we need to allocate a slice for 1M entries.
-Based on the measurements, this will generate a sudden spike in the live heap size, around 145-150 MiB. If people repeatedly do this, the memory allocation of YuniKorn can increase very quickly, possibly resulting in a termination of the YuniKorn pod by the kubelet.
-
-#### **Stream new events directly from ring buffer**
-
-Instead of notifying receivers directly, we just insert the data into the ring buffer.
-For every client, we create a cursor which points to a given position inside the buffer.
-If the pointer is behind the tail, it just keeps reading and going forward until it reaches the current tail.
-
-Although this method sounds simple on the surface, the implementation is complicated:
-
-- When sending the history, we can't rely on `len(buf)` checking.
-It is because when we are sending the history, we are always very close to the capacity.
-Unlike the previous solution, we are processing elements from the buffer directly, and we do not bridge two channels.
-If we do that, we just add further complications.
-Therefore, we have to calculate the sending rate, at least while sending past objects.
-If the pointer is not making progress (or just very slow), then the tail of the ring buffer will catch up to it, but it can take a very long time.
-- In case of multiple cursors, we have to maintain which one is the closest to the tail.
-If we don't do that, we have to check every cursor when adding elements.
-We cannot wait for a slow reader to jump to the next element, so we have to invalidate the cursor, then have to calculate which is the nearest to tail again.
-- Whenever we reach the last element, we have to block and utilize the well-known wait-notify pattern (`Cond.Broadcast()` and `Cond.Wait()` in Go).
-- The overall sending logic is much more complicated: keep reading batches from the ring buffer until we reach the last element, then switch to wait-notify and block.
-
-The advantage of this method is that we don't need large channel buffers to make sure that they don't get filled while sending historical records.
-If the reader is fast enough, we just keep marshalling `si.EventRecord` objects and bump the pointer to the next element.
-
-[^1]: https://pkg.go.dev/strconv#ParseBool
-
-[^2]: https://pkg.go.dev/strconv#ParseUint
diff --git a/versioned_docs/version-1.5.0/design/preemption.md b/versioned_docs/version-1.5.0/design/preemption.md
deleted file mode 100644
index 0106bddc7a..0000000000
--- a/versioned_docs/version-1.5.0/design/preemption.md
+++ /dev/null
@@ -1,581 +0,0 @@
----
-id: preemption
-title: Preemption
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Preemption Design
-
-## Introduction
-
-This design is created to replace the preemption code that has been part of
-YuniKorn for a long time.
-
-The original code was never fully tested. After the core cache removal as part
-of [YUNIKORN-317](https://issues.apache.org/jira/browse/YUNIKORN-317) the
-preemption code was taken out of the scheduling path. The only changes that
-have gone into the preemption code were compilation fixes. As part of the
-preparation for the new preemption design the old code was removed in
-[YUNIKORN-1269](https://issues.apache.org/jira/browse/YUNIKORN-1269).
-
-Preemption of workloads is a feature used by almost all schedulers to help
-critical workloads run. The criticality can be based on the fact that the
-system cannot work without it, i.e. DaemonSets on K8s, or based on some
-other factors like SLA or priority. Preemption for DaemonSet pods was
-implemented as part of
-[YUNIKORN-1085](https://issues.apache.org/jira/browse/YUNIKORN-1085). This
-design thus focuses on preemption for all other workloads.
-
-## Goals
-
-* Re-use existing Kubernetes objects
-* Implement inter-queue preemption
-* Priority knowledge inside the core scheduler to support preemption
-
-## Non Goals
-
-* Intra-queue preemption
-* Cross node preemption
-* Full priority support
-
-## Preemption and Priorities
-
-### Kubernetes
-
-All pods for the entire cluster, across namespaces, are sorted based on
-priority for scheduling. A higher-priority will get scheduled before a
-lower-priority pod. Preemption within the Kubernetes scheduler is also
-based solely on the priority of the pod that is being scheduled. The
-full documentation can be found
-[here](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/).
-
-The simple rule that governs both scheduling order and preemption behavior is
-that a pod with a higher priority is more important than a pod with a lower
-priority. This crosses namespaces. There are no boundaries or limitations
-that can be set. Pods from a namespace with a higher priority are scheduled
-earlier and could trigger the preemption of a pod from another namespace.
-
-Priority of a pod is defined in the pod specification. Priority is a number,
-but is referenced in the pod specification via a PriorityClass object. The
-object defines a named priority and maps it to a value. In more recent
-versions (Kubernetes 1.24 and later), the PriorityClass can also contain a
-preemption policy for the scheduling phase. This preemptionPolicy only allows
-the pod to opt-out from preempting other lower priority pods during the
-scheduling phase. It cannot, and is not designed to, alter preemption behavior
-while the pod is running.
-
-The same pod priority is also used during the pod eviction by the kubelet on
-the node. For example, if the node has been overloaded and runs out of memory
-or CPU, the node can evict pods. These evictions help to keep the node stable.
-Pods considered for eviction are ranked on priority among some other factors.
-
-### YuniKorn
-
-The behavior in Kubernetes is all focused on the scheduling cycle. When
-looking at preemption from the standpoint of a batch or data processing
-workload, we need to take into account the possibility to opt-out while
-running. This option does not exist in the current configuration for workloads.
-
-The simple approach for preemption fits in with the service type workloads
-that Kubernetes is designed for. Services handle the scale up and or scale
-down that could be triggered by preempting one of the pods for that service.
-
-This is not the case when we look at a Spark job as an example. The driver pod
-is the manager of the other pods that belong to the same job. When the driver
-gets preempted the whole job is impacted. Preempting a driver has a follow-on
-effect that could cause multiple pods to be removed from the cluster. For a
-large job that could mean hundreds of pods. The impact is far larger than a
-single pod. Preempting a manager or originator pod should be prevented as much
-as possible.
-
-The other case which we need to account for is an interactive session that
-runs on the cluster. This interactive session, like a python notebook, is a
-one-off instance and restarts have a wider impact. Preempting an instance
-like a notebook is not a desirable outcome either.
-
-Building in all the smarts to know which pods to avoid is difficult, or even
-impossible. For all these cases the option to allow a “do not preempt me” flag
-on the pod would be required. The design will discuss this option in the Pod
-specification.
-
-### Priority limitations
-
-PriorityClass objects which define the priority in a Kubernetes cluster are
-cluster-wide objects. The cluster administrator defines the objects and thus
-the supported priorities.
-
-There are no limitations on the priority that can be set on a pod. When a pod
-is submitted the only check performed is that the PriorityClass specified as
-part of the pod specification is defined. Any rogue user can create a pod with
-the highest defined priority.
-
-Limiting priorities is possible but requires an API server flag which is
-difficult to support in public cloud environments. We cannot rely on the option
-to be available in a cluster scheduled by YuniKorn.
-
-## The Laws of Preemption
-
-Prior knowledge of implementing preemption in the Apache YARN scheduler has
-been used to create this design. It forms the basis for the "laws of preemption".
-These laws, or rules, describe overall preemption behavior.
-
-Preemption for YuniKorn is based on the hierarchical queue model and guaranteed
-resources assigned to a queue.
-
-Preemption is used to get the usage of a queue to at least its guaranteed
-resource capacity. It cannot guarantee that every queue will get its
-guaranteed resource capacity. There are cases that make it impossible to get to
-that state. Preemption therefore does not guarantee a final optimal state can
-or will be reached. The end state of the queues will normally thus be a usage
-that is approximately the guaranteed resource capacity.
-
-An example case that makes it impossible to reach the optimal state is when the
-sum of the guaranteed resources for a group of queues is larger than the current
-resources available in the cluster. It is impossible to get all queues their
-guaranteed resources. More cases like this exist in a hierarchy with maximum
-quotas set at a certain point in the hierarchy preventing the optimal state from
-being reached.
-
-First an overview of the laws, then the explanation and rationale behind each
-of the rules:
-
-1. Preemption policies are strong suggestions, not guarantees
-2. Preemption can never leave a queue lower than its guaranteed capacity
-3. A task cannot preempt other tasks in the same application
-4. A task cannot trigger preemption unless its queue is under its guaranteed
- capacity
-5. A task cannot be preempted unless its queue is over its guaranteed capacity
-6. A task can only preempt a task with lower or equal priority
-7. A task cannot preempt tasks outside its preemption fence (one-way constraint)
-
-Most of the rules given around tasks and queues are there to prevent a
-preemption storm or loop. Preempting a task that could trigger a follow-up
-preemption should be avoided. The rule described should warrant against that.
-Breaking the rules could lead to unpredictable behavior either during
-scheduling or application runs.
-
-### Preemption policies are strong suggestions, not guarantees
-
-A pod is able to request not to be preempted. However, this is not a guarantee.
-There could be circumstances that the scheduler might still preempt the pod.
-This will be a last resort action if no other solution is available. This means
-that the preemption policy is a strong suggestion, not a guarantee.
-
-The example use case that could break the rule and preempt a pod that opted out
-of preemption is the DaemonSet case. The DaemonSet pod must run on the specified
-node. If all pods that are running on that node are either other DaemonSet pods
-or pods that have opted out of preemption there is no other choice. A pod that
-opted out of preemption will be preempted.
-
-### Preemption can never leave a queue lower than its guaranteed capacity
-
-Guaranteed resource capacities configured on a queue are the optimal resources
-for the queue from a preemption point of view. Since preemption attempts to get
-a queue at least its guaranteed resources, allowing preemption to reduce a queue
-below its guaranteed resource capacity would trigger a further round of
-preemption.
-
-When a task is considered for preemption the removal of the task from the
-queue's usage must not leave the queue below its guaranteed resource capacity.
-If the removal of the task would drop the queue below its guarantee that task
-cannot be a candidate.
-
-This could mean that a queue, even when it is above its guarantee, still does
-not allow preempting any of the tasks in that queue.
-
-### A task cannot preempt other tasks in the same application
-
-As part of the current design we are only implementing inter-queue preemption.
-This rule does not apply for inter-queue preemption. It is documented here to
-make extending to intra-queue preemption possible without a rule change.
-
-When a task is considered for preemption the task that triggered the preemption
-cannot be from the same application.
-
-### A task cannot trigger preemption unless its queue is under its guaranteed capacity
-
-Preemption attempts to get a queue at least its guaranteed resources. Allowing
-preemption for a task in a queue that is already over its guaranteed resource
-capacity does not help reaching that goal.
-
-Preemption is not the tool to get a queue to its full maximum resource
-capacity. For that reason no tasks in a queue are allowed to trigger
-preemption in this case. Normal scheduling will handle the assignment of
-resources for queues above their guaranteed capacity.
-
-### A task cannot be preempted unless its queue is over its guaranteed capacity
-
-This is an extension to the rule that prevents a queue from going below its
-guaranteed resource capacity. If a queue is already below its guaranteed
-capacity, no tasks running in that queue can be considered for preemption.
-The queue can already trigger preemption of tasks from other queues. Allowing
-preemption to remove more resources from the queue would cause the queue to be
-even further from its ideal usage.
-
-### A task can only preempt a task with lower or equal priority
-
-This rule is linked to the default preemption behavior of Kubernetes. There is
-however a slight difference when compared to the Kubernetes rule. Kubernetes
-only allows pods to preempt other pods with a lower priority, not with equal
-priority.
-
-Preemption in YuniKorn has a slightly broader application as we also use it to
-allow a queue to use its guaranteed resource capacity. The equality has been
-added to allow pods from the same priority running in two different queues to
-preempt each other. Without that equality allowance on priorities that
-redistribution would be slow and difficult.
-
-### A task cannot preempt tasks outside its preemption fence
-
-This last rule is a specific multi-tenancy rule. YuniKorn allows setting up a
-preemption fence on a queue that will limit the possible tasks that can be
-considered for preemption. A task can only preempt another task if it runs on
-a queue that is located inside the preemption fence. More on preemption
-fencing below.
-
-## Preemption Fence
-
-In a cluster that runs workloads for multiple tenants preemption should not be
-allowed to preempt a workload from one tenant and give the resources to
-another. A tenant in this case does not have to be a company, it could be a
-division or business group within the same company. Tenants map to the queue
-hierarchy. The queue hierarchy can thus cross tenant boundaries.
-
-To translate this to a YuniKorn centric view: confining preemption to assess
-only a part of the queue hierarchy should be possible. For this we want to
-introduce a preemption fence. The preemption fence is a setting on the queue
-which stops preemption from looking at queues outside the fence boundary.
-
-The preemption fence can be set on any queue at any point in the hierarchy.
-It blocks traversing up the queue hierarchy when looking for a victim to
-preempt. The fence is a unidirectional fence. It prevents going out (i.e.
-higher up the queue hierarchy), but does not prevent coming in (or down) the
-queue hierarchy. The below diagram shows an example hierarchy with preemption
-fencing applied:
-
-
-
-The example has three preemption fences defined at different levels. The
-arrows describe the preemption flows.
-
-First look at `queue A`.
-A fence is defined on the leaf queue which means that preemption is fenced to
-that queue. This would limit tasks to find a preemption victim within the
-queue. This in effect turns off inter-queue preemption for the leaf
-`queue A`. This would be a case for intra-queue preemption only. Note that in
-the current design intra-queue preemption is excluded, and we will not
-implement this use case. However, we do allow the configuration to be set.
-
-The second fence is set up at the `tenant 1` level. This fence has an impact
-on the task running in `queue B`. The tasks in `queue B` can find a victim
-to preempt in all queues below the `tenant 1` queue (shown in the diagram with
-the _yellow_ arrows).
-
-A similar setup is created for the `tenant 2` queue. However, in this case
-there can be preemption from `queue 1` to `queue 2` and vice-versa (shown in
-the diagram with the _blue_ arrows).
-
-None of the tasks running in the queues below `tenant 1` or `tenant 2` can
-preempt a task from the `system` queue. Tasks in the `system` queue are not
-fenced. That means that a task in the `system` queue can check any queue in
-the hierarchy (shown in the diagram as the _red_ arrows).
-
-## Preemption Logic
-
-For preemption to be triggered by the default Kubernetes scheduler, the pod
-must fit within any namespace quota and no node can be found to allocate the
-pod on. Preemption tries to find a node to run the pod on and is focused on
-nodes only. All pods on a node with a lower priority are considered candidates
-for preemption. The scheduler reduces the candidates to a victim list just
-large enough to fit the new pod.
-
-The scheduler tracks the node undergoing preemption in the pod that triggered
-the preemption. It does not guarantee, for a number of reasons, that the pod
-that triggered the preemption also gets scheduled on the node the pods were
-preempted from.
-
-From the YuniKorn side we already have a node focused preemption for DaemonSet
-pods. A pod from a DaemonSet must run on a specific node. Preemption is
-focused on making space on that node. YuniKorn guarantees that the pod will
-run on that node and nothing else will be scheduled on that node until the
-DaemonSet pod is scheduled.
-
-Generic preemption in YuniKorn is linked to a queue that is under its
-guaranteed quota (**rule 4**). The preemption is only triggered after a delay.
-A request must have been pending for at least the preemption delay before
-preemption will be considered for it. Instead of looking at a node the first
-step is to find victims based on the queue that is over its guaranteed quota
-(**rule 5**). If no queues can be found within the preemption fence
-(**rule 7**), preemption immediately stops.
-
-The next step is to build a list of victims. This could be from one or
-multiple queues. Any pod with a priority higher (**rule 6**) than the pod
-triggering the preemption is discarded. The next step is to discard any pod
-with resources larger than the over guarantee portion (**rule 2**). Proximity
-of the victim queue in the hierarchy to the originating queue that triggers
-the preemption might be considered when we decide which victims to preempt.
-Details will be worked out during the implementation phase.
-
-Cross node preemption is not supported. Any set of victims that get preempted
-must run on the same node. The victims are split into groups per node. A group
-of victims, combined with the allocatable space on the node, will decide if
-the group is a viable group. Checks must be run to make sure that the pod
-will fit the node before starting the preemption. If more than one group is
-viable a choice will need to be made. The logic for choosing a group is an
-implementation detail.
-
-After choosing a group and indirectly a node, the node is reserved for the
-pod. Preemption for the victim list will be triggered and on completion the
-pod will be scheduled on the node. The reservation guarantees that the pod
-triggering the preemption will be scheduled on that node. As a side effect
-the preempted pods that restart can also not “slip back” into the freed up
-space on the node while the scheduler waits for all preempted pods to exit.
-They could be scheduled on a different node but not stop the pod that
-triggered the preemption from being scheduled.
-
-## Preemption Loop Prevention
-
-The rules defined prevent looping and circular preemptions. Testing should
-be added to cover each rule and combinations like below.
-
-ReplicaSets are a good example to look at for looping and circular
-preemption. Each time a pod from a replica set is removed the ReplicaSet
-controller will create a new pod to make sure the set is complete. That
-auto-recreate could trigger loops if the rules are not covering all cases
-correctly. The case described below should be covered as part of standard
-testing.
-
-Example setup: Replica set _Prod Repl_ runs in queue _Prod_. For testing
-a replica set _Test Repl_ runs in the queue _Test_. Both queues belong
-to the same parent queue (they are siblings). The pods all run with the
-same settings for priority and preemption. There is no space left on the
-cluster.
-
-Example 1: _Prod_ is under its guaranteed quota and multiple pods of the
-replica set are pending. All pods for the _Test Repl_ set are running and
-_Test_ is above its guaranteed resource capacity.
-
-Preemption flow case 1: To make room for a _Prod Repl_ pod, a pod from
-the _Test Repl_ set is preempted. Both queues will end up above their
-guaranteed resource. The _Test Repl_ pod is recreated. It cannot preempt
-the _Prod Repl_ pod as that would leave the _Prod_ queue below its
-guaranteed resource capacity. The _Test Repl_ pod will have to wait until
-resources become available in the cluster. The other pods for the
-_Prod Repl_ set will also have to wait. The _Prod_ queue is now above its
-guaranteed resource and cannot trigger preemption anymore.
-
-Preemption flow case 2: _Test_, although above its guaranteed resource
-capacity, would end up below its guarantee if a pod from _Test Repl_ would be
-preempted. No preemption happens and the _Prod Repl_ pods will stay pending
-until space becomes available in the cluster.
-
-Preemption flow case 3: To make room for the _Prod Repl_ pod a pod from the
-_Test Repl_ set is preempted. The _Prod_ queue, even with the additional pod,
-is still below its guaranteed resource. The _Test Repl_ pod is recreated.
-_Prod_ is not considered as a queue with victims as it is still below its
-guaranteed resources. The _Test Repl_ pod will have to wait until resources
-become available in the cluster. The _Prod_ queue can trigger further
-preemptions. Preemption checks start from scratch. Depending on the state this
-could trigger none or more preemptions from the Test queue.
-
-## Preemption Configuration
-
-### PriorityClass
-
-As part of the pod specification we need to be able to provide the ability to
-opt-out of preemption. Allowing a user to specify the opt-out directly on the
-pod independent of the priority causes a disconnect between Kubernetes and
-YuniKorn preemption configuration. It also removes control from the
-administrator of the cluster to define which priorities should not be able
-to opt out.
-
-One of the goals of the design is to not introduce new objects in Kubernetes.
-Combined with the above control and management of the opt-out functionality
-at a cluster level the design reuses the existing PriorityClass object.
-We cannot and must not break existing functionality of the default Kubernetes
-scheduler when we do this. The plugin version of Kubernetes relies on the
-default scheduler and its behavior. Pods will use the priorityClassName just
-like standard Kubernetes.
-
-The PriorityClass object allows specifying a _preemptionPolicy_ with two
-possible values:
-* PreemptLowerPriority
-* Never
-
-The values are hard-coded in the core types and validations. Adding a new
-value is not possible without making a Kubernetes change. That means we cannot
-reuse the _preemptionPolicy_ field itself. The content of the field will be
-propagated to the scheduling core to allow YuniKorn to take the setting into
-account while scheduling.
-
-Just like all other objects in Kubernetes, the PriorityClass object extends
-the base object and includes metadata. As part of the metadata we can set
-labels and or annotations on the object. Labels are more restrictive than
-annotations. As a generic rule we prefer to use annotations over labels for
-all the extensions we are adding.
-
-The proposal is to add an annotation to the PriorityClass that allows an
-opt-out of preemption. The name of the annotation would follow the same
-structure as we use for all other annotations:
- `yunikorn.apache.org/allow-preemption`
-
-As the value of the annotation the proposal is to use a boolean value:
-* "true": allow the pod to be preempted,
-* "false": do not allow preemption
-If no value is set for _allow-preemption_ the default value _true_ is used.
-
-The design comes with a caveat. The value of "_false_" for the annotation
-on the PriorityClass provides the possibility for a pod to request not to
-be preempted. However, this is not a guarantee. There could be
-circumstances that the scheduler might still preempt the pod. This will be
-a last resort action if no other solution is available. This means that the
-preemption policy as defined above is a strong suggestion, not a guarantee.
-
-The example use case that could break the rule and preempt a pod with
-_allow-preemption_ set to _false_ is the DaemonSet case. The DaemonSet pod
-must run on the specified node. If all pods that are running on that node
-are either other DaemonSet pods or pods that have _allow-preemption_ set
-to _false_ there is no other choice. A pod that opted out of preemption
-will be preempted.
-
-### Application Settings
-
-Priority is part of the pod specification on Kubernetes. Every pod is
-converted into an AllocationAsk by the k8shim. As part of the DaemonSet
-preemption that was implemented in
-[YUNIKORN-1085](https://issues.apache.org/jira/browse/YUNIKORN-1085) the
-priority of a pod is read and set on the AllocationAsk that is created. The
-priority that is passed on currently is just a plain integer value, we do not
-need more than that.
-
-As part of preemption we need two additional values to be passed on. These two
-values together form the preemptionPolicy for YuniKorn. The values must be
-communicated as part of the AllocationAsk sent from the Kubernetes shim to the
-core. Both values are mapped to the content of the PriorityClass described above.
-Instead of adding two separate fields, wrapping them into a new message will
-provide more clarity.
-
-The preemption policy can be processed for any AllocationAsk, even if it has
-the `Originator` flag in the message set to _false_. Specifying different
-preemption behavior for different asks within an application could be important
-to allow low-cost asks to be preempted while high-cost asks opt-out.
-
-The use case is again a Spark application. You want the driver pod to opt-out
-from preemption and, possibly, preempt other pods during scheduling. An executor
-should do neither.
-
-In protobuf message form that would look like:
-
-```
-message AllocationAsk {
- ...
- // The preemption policy for this ask
- PreemptionPolicy preemptionPolicy = 12;
-}
-
-message PreemptionPolicy {
- // Allow preemption while running
- // Based on the YuniKorn annotation from the PriorityClass object
- bool allowPreemption = 1;
- // Preemption behavior while scheduling
- // Based on the K8s preemptionPolicy from the PriorityClass object
- string schedulerPreemption = 2;
-}
-```
-
-### Queue Configuration
-
-Two new attributes will be added to the queue configuration object to allow
-specifying the preemption fence type and preemption delay. Both properties,
-`preemption.policy` and `preemption.delay`, can be set on any queue. The
-attributes are part of the queue properties as follows:
-
-```yaml
-queues:
- - name: fencedqueue
- properties:
- preemption.policy: fence
- preemption.delay: 30s
-```
-
-Properties are fully supported in child templates. Support for setting these
-properties for dynamic queues is included as part of the existing
-functionality.
-
-The _preemption.policy_ property can be set on the root queue but has no effect.
-The root queue as the top of the hierarchy has no parent. This means preemption
-cannot traverse further up the tree. No messages will be logged if the
-_preemption.policy_ is set on the root queue.
-
-The supported values for the _preemption.policy_ are:
-* default
-* fence
-* disabled
-
-If the value `fence` is set on a queue, tasks running in or below the queue on
-which the property is set cannot preempt tasks outside the queue tree. The
-value `default` does not limit preemption to the subtree. If no policy is set
-the value `default` is used.
-
-A _preemption.delay_ can only be set on a leaf queue. The leaf queue contains
-the tasks. Tasks trigger the preemption in combination with a queue being below
-its guaranteed resource capacity. Setting a preemption delay on a queue that is
-not a leaf has no effect. No messages will be logged if a _preemption.delay_ is
-set on a parent queue.
-
-The _preemption.delay_ value must be a valid Golang duration in string form. The
-value will be converted into a duration using `ParseDuration` as defined in the
-time package.
-
-A _preemption.delay_, if specified, must be larger than `0s`. If no
-_preemption.delay_ property is specified in the queue the default of `30s` is
-used. If parsing of the string fails the default of `30s` is used.
-
-## Scheduler storage object changes
-
-### AllocationAsk
-
-In line with the changes for the communication the objects in the scheduler also
-need to be modified to persist some of the detail communicated. For the
-AllocationAsk we need to store both new fields.
-
-Proposed new fields: _allowPreemption_ and _schedulerPreemption_
-
- - _schedulerPreemption_ is only used during the scheduling phase.
- - _allowPreemption_ will be propagated to the resulting allocation as defined
- below.
-
-### Allocation
-
-The allocation that gets created based on the AllocationAsk needs a new field.
-This removes the need to check the underlying AllocationAsk if it allows
-preemption or not. The scheduler preemption value is not required in the
-Allocation.
-
-Proposed new field: _allowPreemption_
-
-### Queue
-
-The new preemption policy and delay values will need to be stored in the Queue
-object. The configuration object does not change as we use the properties of
-the Queue in the configuration to store them.
-
-Proposed new fields: _preemptionPolicy_ and _preemptionDelay_
diff --git a/versioned_docs/version-1.5.0/design/scheduler_configuration.md b/versioned_docs/version-1.5.0/design/scheduler_configuration.md
deleted file mode 100644
index 54b616a4ec..0000000000
--- a/versioned_docs/version-1.5.0/design/scheduler_configuration.md
+++ /dev/null
@@ -1,246 +0,0 @@
----
-id: scheduler_configuration
-title: Scheduler Configuration
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-The Yunikorn core scheduler configuration has two separate areas that need to be configured. The scheduler service itself, things like web service ports etc, and the queue configuration. The split between the two types of configuration is proposed with two points in mind:
-* Separation of duty
-* Dynamic vs Static
-
-The scheduler configuration is mainly static. There is no need to change a web service port or a scheduling policy while the service is running. The queue configuration is far more dynamic and can change while the service is running.
-
-From a separation of duty we can allow an operator that manages the cluster to make changes to the scheduler queues. You would not want to allow that administrator to change the scheduler configuration itself.
-
-Separated from the core scheduler configuration we have one or more shim configurations. We currently cannot anticipate the deployment model of the scheduler and its shims. A shim, like the k8s-shim, might run in the same container or node but there is no guarantee it will. We also do not know the number of shims that will be used with one core scheduler. There is also still the possibility to have multiple instances of the same shim with one core scheduler.
-
-Shim configuration must be independent of the core scheduler configuration.
-## Scheduler Configuration
-Scheduler configuration covers all the configuration needed to start the scheduler and the dependent services. The configuration consists of a simple key value pair. All configuration to start the service must be part of this configuration.
-The scheduler configuration must exclude the queue related configuration.
-
-Scheduler configuration as currently identified
-* Bind host
-* Service port
-* Web bind host
-* Web service port
-* SSL config
-* Shims Configured
-* SchedulerACL
-
-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
-## 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.
-Based on the kubernetes definition this configuration could be a configMap <sup id="s1">[1](#f1)</sup> but not a CRD.
-
-The queue configuration is dynamic. Changing the queue configuration must not require a scheduler restart.
-Changes should be allowed by either calling the GO based API, the REST based API or by updating the configuration file. Changes made through the API must be persisted in the configuration file. Making changes through an API is not a high priority requirement and could be postponed to a later release.
-
-The queue configuration defines queues in a hierarchy: a tree. The base of the tree is the _root_ queue. The queue configuration must define a single _root_ queue. All queues that are defined in queue configuration are considered _managed_ queues.
-
-The root queue reflect the whole cluster. Resource settings on the root queue are not allowed. The resources available to the root queue are calculated based on the registered node resources in the cluster. If resources would be specified on the root limit the cluster would either be artificially limited to a specific size or expect resources to be available that are not there.
-
-Queues in the hierarchy in the tree are separated by the “.” dot character (ASCII 0x2E). This indirectly means that a queue name itself cannot contain a dot as it interferes with the hierarchy separator. Any queue name in the configuration that contains a dot will cause the configuration to be considered invalid. However we must allow placement rules to create a queue with a dot based input.
-
-Not all queues can be used to submit an application to. Applications can only be submitted to a queue which does not have a queue below it. These queues are defined as the _leaf_ queues of the tree. Queues that are not a _leaf_ and thus can contain other queues or child queues are considered _parent_ queues.
-
-Each queue must have exactly one _parent_ queue, besides the root queue. The root queue cannot have a _parent_ and will be automatically defined as a _parent_ queue type.
-A fully qualified queue name, case insensitive, must be unique in the hierarchy. A queue in the hierarchy can thus be only uniquely identified by its fully qualified path. This means that a queue with the same name is allowed at a different point in the hierarchy.
-Example:
-```
-root.companyA.development
-root.companyB.development
-root.production.companyA
-```
-In the example the queues _companyA_ and _companyB_ are _parent_ queues. Both _development_ queues are _leaf_ queues.
-The second instance of the _companyA_ queue is a _leaf_ queue which is not related to the first instance as it is defined at a different level in the hierarchy.
-
-The queue as defined in the configuration will be assigned a queue type. This can either be implicit based on how the queue is defined in the hierarchy or explicit by setting the optional _parent_ property as part of the queue definition. By default all queues will be assigned their type based on the configuration. There is only one case in which this should automatic process would need to be overridden and that is to mark a _leaf_ in the configuration as a _parent_. The use case is part [...]
-
-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.
-
-On each queue, except the root queue, the following properties can be set:
-* QueueType:
- * Parent (boolean)
-* Resource settings:
- * Guaranteed (resource)
- * Maximum (resource)
-* Running Application limit:
- * Maximum (integer)
-* Queue Permissions:
- * SubmitACL (ACL)
- * AdminACL (ACL)
-* Pre emption setting:
- * PreEmptionAllowed (boolean)
-* Application sort algorithm:
- * ApplicationSortPolicy (enumeration: fair, fifo)
-
-On the root queue only the following properties can be set:
-* Running Application limit:
- * Maximum (integer)
-* Queue Permissions:
- * SubmitACL (ACL)
- * AdminACL (ACL)
-* Application sort algorithm:
- * ApplicationSortPolicy (enumeration: fair, fifo)
-
-### User definition
-Applications are run by a user could run in one or more queues. The queues can have limits set on the resources that can be used. This does not limit the amount of resources that can be used by the user in the cluster.
-
-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:
-* Running Application limit:
- * Maximum (integer)
-* Resource setting:
- * Maximum (resource)
-
-### Placement Rules definition
-Schedulers can place an application in a queue dynamically. This means that an application when submitted does not have to include a queue to run in.
-
-A placement rule will use the application details to place the application in the queue. The outcome of running a placement rule will be a fully qualified queue or a `fail`, which means execute the next rule in the list. Rules will be executed in the order that they are defined.
-
-During the evaluation of the rule the result could be a queue name that contains a dot. This is especially true for user and group names which are POSIX compliant. When a rule generates a partial queue name that contains a dot it must be replaced as it is the separator in the hierarchy. The replacement text will be `_dot_`
-
-The first rule that matches, i.e. returns a fully qualified queue name, will halt the execution of the rules. If the application is not placed at the end of the list of rules the application will be rejected. Rules can return queues that are not defined in the configuration only if the rule allows creation of queues.
-
-These queues created by the placement rules are considered _unmanaged_ queues as they are not managed by the administrator in the configuration. An administrator cannot influence the _unmanaged_ queue creation or deletion. The scheduler creates the queue when it is needed and removes the queue automatically when it is no longer used.
-
-Rules provide a fully qualified queue name as the result. To allow for deeper nesting of queues the parent of the queue can be set as part of the rule evaluation. The rule definition should allow a fixed configured fully qualified parent to be specified or it can call a second rule to generate the parent queue. By default a queue is generated as a child of the root queue.
-
-Example:
-Placing an application submitted by the user _user1_ whom is a member of the groups _user1_ and _companyA_ in a queue based on UserName:
-```
-Rule name: UserName
- Parent: root.fixedparent
-Result: root.fixedparent.user1
-
-Rule name: UserName
- Parent: SecondaryGroup
- Filter:
- Type: allow
- Groups: company.*
-Result: root.companyA.user1
-
-Rule name: UserName
-Filter:
- Users: user2,user3
-Result: denied placement
-```
-The default behaviour for placing an application in a queue, which would do the same as using the queue that is provided during submit, would be a rule that takes the provided queue with the create flag set to false.
-
-Access permissions will be enforced as part of the rule evaluation. For _managed_ queues this means that the ACL for the queue itself is checked. For an _unmanaged_ queue the parent queue ACL is the one that is checked. For the definition of the access control list and checks see the [Access Control Lists](#access-control-lists) chapter.
-
-Defining placement rules in the configuration requires the following information per rule:
-* Name:
- * Name (string)
-* Parent
- * Parent (string)
-* Create Flag:
- * Create (boolean)
-* Filter:
- * A regular expression or list of users/groups to apply the rule to.
-
-The filter can be used to allow the rule to be used (default behaviour) or deny the rule to be used. User or groups matching the filter will be either allowed or denied.
-The filter is defined as follow:
-* Type:
- * Type (string) which can have no value (empty) or "allow" or "deny", case insensitive.
-* Users:
- * A list of zero or more user names. If the list is exactly one long it will be interpreted as a regular expression.
-* Groups:
- * A list of zero or more group names. If the list is exactly one long it will be interpreted as a regular expression.
-
-Proposed rules for placing applications would be:
-* Provided: returns the queue provided during the submission
-* UserName: returns the user name
-* PrimaryGroupName: returns the primary group of the user
-* SecondaryGroupName: returns the first secondary group of the user that matches
-* Fixed: returns the queue name configured in the rule
-* ApplicationType: returns the application type (if available)
-
-For _unmanaged_ queues in the current revision of the configuration you cannot provide any queue specific properties. However in the future we should consider propagating specific resource related settings from a _managed_ parent to the _unmanaged_ child, specifically:
-* Dynamic Resource settings:
- * Guaranteed (resource)
- * Maximum (resource)
-* Dynamic Running Application limit:
- * Maximum (integer)
-
-### Configuration updates
-Updating the queue definition will allow updating the existing queue properties as well as adding and removing queues. A new queue definition will only become active if the configuration can be parsed. The change of the definition is an atomic change which applies all modification in one action.
-
-Updating the queue properties will not automatically trigger further action. This means that if the maximum number of resources of a queue or its parent is changed we leave the applications in the queue running as they are. The scheduler will adhere to the new property values which should see the convergence over time.
-
-A _managed_ queue will only be removed if it is removed from the configuration. Before we can remove a queue it must not be running applications. This means that when a _managed_ queue is removed from the configuration it must be empty or the system needs to allow the queue to drain. Forcing a _managed_ queue to be empty before we can remove it is not possible which means that _managed_ queues are removed in multiple steps:
-1. The queue is removed from the configuration
-1. The queue is marked as `draining`
-1. All managed queues that are `draining` and empty are removed
-
-Long running applications should be handled gracefully when removing a _managed_ queue. The scheduler should at least track and expose that a queue has been in a _draining_ state for an extended period of time. In the optimal case the application should be notified of the queue change to allow it to release resources. In all cases the queue administrators should be notified to allow them to take action. This action would currently be a manual move of the application to a different queue [...]
-
-_Unmanaged_ queues that are not defined in the queue definition are created by the scheduler automatically based on the placement rules. _Unmanaged_ queues have a lifespan independent of the configuration. Whenever an _unmanaged_ queue is empty it will get removed. The queue will automatically be created again when a new application is requesting it via triggering the placement rule.
-
-Removing an empty _managed_ or _unmanaged_ queue is handled by the same removal code which must run independent of the configuration updates and scheduling actions.
-
-Configurations can change over time. The impact of a fail over or restart must still be investigated.
-Base point to make: a changed configuration should not impact the currently running applications. Queues that no longer exist should be handled somehow.
-
-### Access Control Lists
-The scheduler ACL is independent of the queue ACLs. A scheduler administrator is not by default allowed to submit an application or administer the queues in the system.
-
-All ACL types should use the same definition pattern. We should allow at least POSIX user and group names which uses the portable filename character set <sup id="s2">[2](#f2)</sup>. However we should take into account that we could have domain specifiers based on the environment that the system runs in (@ sign as per HADOOP-12751).
-
-By default access control is enabled and access is denied. The only special case is for the core scheduler which automatically adds the system user, the scheduler process owner, to the scheduler ACL. The scheduler process owner is allowed to make sure that the process owner can use the API to call any administrative actions.
-
-Access control lists give access to the users and groups that have been specified in the list. They do not provide the possibility to explicitly remove or deny access to the users and groups specified in the list.
-
-The access control list is defined as:
-```
-ACL ::= “*” | userlist [ “ “ grouplist ]
-userlist ::= “” | user { “,” user }
-grouplist ::= “” | group { “,” group }
-```
-
-This definition specifies a wildcard of * which results in access for everyone. If the user list is empty and the group list is empty nobody will have access. This deny all ACL has two possible representations:
-* an empty access control list.
-* a single space.
-
-If there is no access control list is configured access is denied by default.
-## Shim Configuration
-The shim configuration is highly dependent on the shim implementation. The k8s shim differs from the YARN shim. Currently the k8s shim is configured via command line options but we should not depend on that.
-
-### K8s shim
-The full configuration of the K8s shim is still under development.
-
-### YARN shim
-The full configuration of the YARN shim is still under development.
-
----
-<br/><b id="f1"></b>1: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource. [↩](#s1)
-<br/><b id="f2"></b>2: The set of characters from which portable filenames are constructed. [↩](#s2)
-<br/>`A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ -`
diff --git a/versioned_docs/version-1.5.0/design/user_group_manager.md b/versioned_docs/version-1.5.0/design/user_group_manager.md
deleted file mode 100644
index 4100ce8fe9..0000000000
--- a/versioned_docs/version-1.5.0/design/user_group_manager.md
+++ /dev/null
@@ -1,410 +0,0 @@
----
-id: user_based_resource_usage_tracking
-title: User Based Resource Usage Tracking
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Introduction
-
-Tracking resource allocation usage is currently limited to a queue. An application, which owns the allocation, is the source of that resource usage. All applications that are part of the queue will count towards the resource usage of the queue. A queue could also have a resource usage quota set. The queue’s resource quota is enforced during the scheduling cycle.
-
-An application is always owned by a user/group. One user/group could own applications in one or more queues. Like a queue a user/group could have a limit set. A limit can specify a resource usage quota, and an application usage limit. Tracking these usages per user/group is currently not implemented and is covered as part of this design.
-
-## Goals
-
-- Specify tracking usage in relation to the following objects:
- - users
- - applications
- - queues
-- An interface to define how to track running applications:
- - Read a user/group running applications
- - Increase a user/group running applications *)
- - Decrease a user/group running applications
-
-- An interface to define how to track usage:
- - Read a user/group resource usage
- - Increase a user/group resource usage *)
- - Decrease a user/group resource usage
-
- *) This call could be extended for enforcement later.
-
-- Expose user/group tracked information through REST API
-
-## Non Goals
-- User and group retrieval is part of the k8shim which is out of scope
-- Exposing usage as a metric into prometheus
-- Specify enforcement rules
-- Implementation of enforcement
-- Interface definition to allow enforcement
-
-## Tracking definitions
-
-### User vs Group tracking
-
-Tracking is based on the _security.UserGroup_ object defined in the core scheduler. User and group information is retrieved by the shim and communicated via the _UserGroupInformation_ object as defined in the scheduler interface. A _security.UserGroup_ object contains:
-- user (exactly 1)
-- groups (0 or more)
-
-Limits can be configured for both users and groups at the same time in the same queue. So, in the case of users for which no limit has been configured explicitly but group (to which the user belongs to) limits have configured works based on the group limits configuration. In case of users for which a limit has been configured explicitly works based on its own configured limits irrespective of whether configuration has been set for the corresponding group (to which the user belongs to) o [...]
-
-"*" is also allowed for both users and groups limit configuration. In this case, any user or group needs to go through enforcement checks to ensure limit settings are being honoured properly. However, the tracker does not need to track the wildcard user as a specific user or group is already being tracked during their activities.
-
-### Group limitations
-
-Users can belong to zero, one or multiple groups. In some systems, like unix, a concept of a primary group exists. This concept is not universal and there is no consistent definition of a primary group either. If the system does not define a primary group how would we distinguish between the groups?
-
-In the case the user is a member of multiple groups the assignment of usage to a group also becomes problematic. The decision which group to assign the usage to becomes arbitrary. As an example consider a user with multiple groups assigned. Joe has groups dev and test assigned. When an application is started does that application count towards the limits for the dev group or against the limits for the test group or both?
-
-The _UserGroup_ object contains a slice, list or array, of groups which has a fixed order from the moment of creation. The group resolution configured might not guarantee an ordering which means we cannot rely on the order in the _UserGroup_ to be stable. A stable and pre-defined way of choosing a group to track usage against must be defined.
-
-The first point to define is that tracking can only occur against zero (0) or one (1) group. Usage can never be tracked against multiple groups. If a user is a member of multiple groups, a group is selected when the first usage is registered for the application. The group selected out of the list of groups in the _UserGroup_ object to track against is based on the hierarchical queue limit configuration. The hierarchy is considered bottom up, starting from the leaf up to the root. The fir [...]
-
-If no group limits are defined, in the hierarchy, usage is not tracked for a group. If no groups are defined in the _UserGroup_ object no usage will be tracked against a group.
-
-The tracker considers only the group received as part of the _UserGroup_ object at the time of first usage registration for the application in the tracker. In case of group changes while the user’s application is actively being tracked, the tracker does not consider the group change. However, If the user submits a new application, the most current group information at that point in time will be used.
-
-Until there is full support for groups in the k8shim, group tracking will be limited. No groups are passed by the k8shim to the core. This results in the _UserGroup_ object in the current implementation to always have only one group. The group name will be the same as the username. We also have excluded configuration processing for the tracking. For the current tracking implementation as described in the document these limitations will result in the user and group linked to the user to t [...]
-
-### Cluster or queue based tracking
-
-Tracking user usage will be based on the usage per queue. The full hierarchy of the queue will be tracked. We should not just track the leaf or root of the hierarchy. The overall cluster usage is the same as the usage of the root queue. Cluster level usage does not need separate tracking.
-
-The overhead of tracking per queue should be really limited. In most cases a user will run their workloads in a specific queue. Deeply nested queues do also add overhead to the tracking. During testing the impact of workload spread and or deep nesting needs to be assessed. If needed this can be called out in the documentation.
-
-We also need to take into account that multiple members of a group could be using different queues in the hierarchy. If tracking usage would be limited to the leaf level, aggregating group usage becomes more difficult and loses transparency.
-
-The documentation around limits, part of the enforcement, reference different limits at different levels for users or groups. Tracking at just the leaf or root level could break that functionality. The design should support the current documented features. If during enforcement design a different decision is made then the tracking is not the deciding factor.
-
-## Application tracking
-
-Applications go through a number of states within the core scheduler. Allocations linked to applications are the triggers for application state changes. From a tracking perspective we need to define what is considered a running application.
-
-Since placeholders and placeholder timeout can play a role in state changes the implementation of the running application tracking must take into account these cases:
-- no gang defined
-- gang defined, all or some placeholders replaced
-- gang style "soft" defined, all placeholders time out
-- gang style "hard" defined, all placeholders time out
-
-### 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.
-
-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.
-
-### Running state exit
-
-An application should be considered running as long as at least one allocation is assigned to the application. The removal of the last allocation should decrease the number of running applications. However, we also need to consider the pending requests.
-
-As part of the application states the application enters into a _Completing_ state when the last allocation is removed and there are no pending requests. This automatically progresses into the _Completed_ state if nothing changes for the application. Applications going into the _Completing_ state all have no allocations left and pending requests are considered. The entry of the _Completing_ state thus could be used as a point for triggering the decrease of the running application count.
-
-However there are circumstances that the application goes from the _Completing_ state back into a _Running_ state. This is linked to auto restart of a pod by Kubernetes. This case must be handled.
-
-A last case that needs to be considered is an application that fails. If an application fails it moves into the Failing state. The application does not enter _Completing_ but could have incremented the running applications. A failure could be triggered by the gang scheduling style "hard" or the removal of a partition.
-
-## Resource usage tracking
-
-Resource usage is tracked simply based on the addition or removal of an allocation.
-
-Removal of an allocation is an out-of-band action. The shim notifies the core scheduler that an allocation no longer exists and the core updates the tracking based on that removal. If an allocation is preempted the core initiates the removal but still gets notified by the shim that the removal has occurred. Until the confirmation of the shim is received no tracking updates must be created.
-
-The replacement of a placeholder by the real allocation for gang scheduling follows a similar concept. However, in that case there is a possibility that there is a discrepancy between the placeholder size and the real allocation. See [YUNIKORN-982](https://issues.apache.org/jira/browse/YUNIKORN-982) for more detailed information on this issue. The changes that fixed the accounting for the queues and nodes also need to be taken into account for user based resource tracking.
-
-Adding a new allocation to an application triggers the update of the tracked resources for the user and or group as described in the [group limitations](#group-limitations). Enforcement is not a goal of the design document but the enforcement implementation needs to be taken into account. The point to add the resource usage must line up with the point that the queue structure is currently updated and the queue quotas are enforced.
-
-The order of the updates: queue structure first then user or user first then queue structure is debatable. The current proposal is to implement the following:
-- Update user and group based usage
-- Queue quota enforcement and update
-- If the queue enforcement fails, roll back the user and group based update.
-
-## Scheduler transparency
-
-Resource usage tracking is based on the allocated resource, and linked to the application’s queue path and the application’s _user_ field. Application tracking is a simple count of the applications, and is linked to the application’s queue path and the application’s user field.
-As an extension on this we could consider adding the _applicationID_ into the tracking of the running applications to help with troubleshooting. This is part of the current proposal. The proposal is to not link the running application tracking to the applicationID.
-
-The user field of an application is the earlier mentioned _security.UserGroup_ object and has all the identifying details needed to track the usage.
-
-From the schedulers perspective there should be no special setup needed. The tracking should always work without the need to pre-create a user, group or queue based entry. This means that the tracking cannot fail even if the user or group has no enforcement linked to it and does not exist in the tracker.
-
-In summary the tracker must implement:
-- User and or group creation on the fly.
-- Auto cleanup of tracking information no longer needed.
-- Configuration processing needed for enforcement.
-
-## User Group Manager (UGM)
-
-Tracking all the resources will be part of a new self-contained module in the scheduler. This means that there must be no imports from the `scheduler.objects` package. This will allow us to run the tracker separately and push updates, if needed, into a background processing queue.
-
-There will be one user group manager created per partition as part of the partition creation process. There will be no tracking of user quotas over a partition boundary.
-
-The new self-contained module, user group manager contains all specifications and code for tracking and can be extended in the future to include enforcement code.
-
-Tracking the resources and application count for all users occurs from startup. This happens irrespective of whether enforcement is configured for the user or group. By starting tracking independently of the enforcement changes in enforcement will always have a consistent view of the resources tracked at least at a user level. Recovery must be tested in combination with the tracking code.
-
-Storing data in the user group manager is based on the _security.UserGroup_ structure content. The built-in _UserGroupCache_ resolution cannot guarantee that the same object is returned for the same user each time.
-
-### UserGroup cache impact
-
-The concept of a stable user entry in the cache is not currently present in the _UserGroupCache_. This concept will most likely also not be possible based on the fact that group resolution does not guarantee ordering. Based on the assumption that we cannot guarantee group ordering for all group resolutions that are possible the tracking will not rely on it.
-
-Currently, _UserGroupCache_ holds the _UserGroup_ object entry only for the cache period. This is either 300 seconds for a positive resolution or 30 seconds for a negative resolution. After this cache time the entry will be deleted as part of the cache cleanup/expiration process. If the same user submits a second application after the expiry, a new _UserGroup_ object will be created and stored in the cache. The _UserGroup_ object has a property "resolved", which holds a timestamp at whic [...]
-
-Other internal changes might be needed to make sure all _UserGroup_ objects are cached correctly and returned as expected internally in the cache. These are left as implementation details for the cache changes.
-
-### Tracking structure
-
-The user group Manager must be able to track usage for users and groups. Users are the primary access point for all tracking. The user group Manager structure will implement the [tracker interface](#tracker-interface).
-
-````
-package user_group_manager
-
-type Manager struct {
- users map[string]*userTracker
- groups map[string]*groupTracker
-
- sync.RWMutex
-}
-(m *Manager) checkAppGroup(queuePath, applicationID string, user *security.UserGroup)
-````
-
-All objects in the user group manager will be managed internally. Creation of user and or group tracker objects is based on the request to track usage. The objects are added to one of the two structures in the user group manager. Adding user or group objects can only be triggered by an increase of tracked resources. The creation of the user and or group tracker objects is handled by the user group manager. The user group manager is also responsible for setting the usage information for t [...]
-
-The resolution of the group that the usage is tracked against for an application is handled by the user group Manager via the checkAppGroup. As part of an increase of resource usage the Manager will check if the application is already tracked for the user. If the application is already tracked nothing changes. If the application is not tracked the manager will resolve the group to track against and update the userTracker object. If there is no active tracker registered for the group a ne [...]
-
-Removal of user or group objects can only be triggered after a decrease of tracked resources has removed the last usage. Usage tracked for a user must be zero. For group tracker objects the application reference count must be zero.
-Removal of the user and or group tracker objects is done periodically. This cleanup must be `go routine` safe. Updates to either map could be triggered from different routines, scheduler allocation processing or a release of an allocation by a shim.
-
-### Tracker interface
-
-The interface describes the functions that will be exposed by the user group manager. The other scheduler components can rely on the functions defined in the interface to be available to increase, decrease applications and or resource usage and get the tracked resources.
-
-```
-package user_group_manager
-
-type Tracker interface {
- GetUserResources(user *security.UserGroup) *Resource
- GetGroupResources(group string) *Resource
-
- GetUsersResources() []*userTracker
- GetGroupsResources() []*groupTracker
-
- IncreaseTrackedResource(queuePath, applicationID string, usage *Resource, user *security.UserGroup) error
- DecreaseTrackedResource(queuePath, applicationID string, usage *Resource, removeApp bool, user *security.UserGroup) error
-}
-```
-
-The _IncreaseTrackedResource()_ and _DecreaseTrackedResource()_ calls will implement the tracking data updates. The Get* calls are providing safe access to the tracked data to be used as part of exposing the data in the REST interface. See [exposure of usage tracking](#exposure-of-usage-tracking) for more detail.
-
-Applications are added automatically during the call to increase the tracked resources. The first time the applicationID is encountered the structures are updated accordingly and tracking starts. The removal of the application is triggered by leaving the [running state](#running-state-exit), this is equivalent to the removal of the last usage and must also set the removeApp flag to true.
-
-Calling _IncreaseTrackedResource()_ and _DecreaseTrackedResource()_ with empty or nil parameters is not allowed and will return an error to be handled by the caller. The _GetUserResource_ and _GetGroupResource_ calls can return a _nil_ Resource value. The _GetUsersResource_ and _GetGroupsResource_ calls can return an empty slice.
-
-### User tracking
-
-The userTracker contains all tracked usage information for a user. Changes for all usage, even the group usage, are part of the change that gets triggered on the user object.
-
-The userTracker object contains a reference map to the usage for each application that is tracked linking it to the groupTracker object for the specific application. Multiple applications can be tracked against the same groupTracker object.
-
-The group references will be set for each application when usage is added for an application and is not mutable. The existence of a groupTracker for the application can be checked by calling _hasGroupForApp_ on the userTracker object. It returns true in case the application ID exists in the group mapping, false if it does not. The return value is only based on the existence of the applicationID as the key, not on the value it references.
-
-The groupTracker can be set in the userTracker object by calling _setGroupForApp_. If the applicationID already exists, the call to set the groupTracker reference is a noop, nothing will change. The reference cannot be changed after it is set. The groupTracker reference can be nil. In the case of a nil reference, no tracking for that application against a group is performed. Even a nil reference cannot be replaced.
-
-An increase or decrease of the resources tracked for the user requires the applicationID to be set to a non-empty value. On removal of the last allocation for the application the group reference will be removed from the userTracker object. To remove a running application from the userTracker the applicationID must be set in the _decreaseResource_ call and the flag removeApp must be set to true. Removal of the groupTracker reference can only occur as part of a _decreaseResource_ call.
-
-If there are no applications left in the group references the object will be removed by the cleanup run from the user group manager. This will also mean that there is no usage tracked anymore by the referenced queueTracker object.
-
-The usage per queue is stored in a queue structure specific for this user. The queueTracker object provides a hierarchical structure. This structure starts at the root of the queue hierarchy and only contains child queues for which a usage is being tracked. The hierarchy must be updated, add or delete of child entries, as part of the updates that are processed.
-
-The creation of the root queueTracker is part of the creating a new userTracker object.
-
-```
-package user_group_manager
-
-type userTracker struct {
- userName string
- group map[string]*groupTracker
- queue *queueTracker
-
- sync.RWMutex
-}
-
-newUserTracker(queuePath string, user *security.UserGroup) *userTracker
-
-(ut *userTracker) increaseResource(queuePath, applicationID string, usage *Resource)
-(ut *userTracker) decreaseResource(queuePath, applicationID string, usage *Resource, removeApp bool)
-(ut *userTracker) hasGroupForApp(applicationID string) bool
-(ut *userTracker) setGroupForApp(applicationID string, groupTrack *groupTracker)
-```
-
-### Group tracking
-
-The groupTracker contains all tracked usage information for a group. This object can be shared by multiple users for one or more applications. It adds the applications that are tracked for this specific group automatically to the list. For this it expects an applicationID to be set to a non-empty value for each _increaseResource_ call.
-
-To simply decrease the resources tracked for the group the applicationID could be empty. On removal of the last allocation for the application the application will be removed from the groupTracker object. To remove a running application from the groupTracker the applicationID must be set in the _decreaseResource_ call and the flag removeApp must be set to true.
-
-If there are no entries left in the applications tracked in the groupTracker the object will be removed by the cleanup run from the user group manager. This will also mean that there is no usage tracked any more by the referenced queueTracker object.
-
-The usage per queue is stored in a queue structure specific for this group. The queueTracker object provides a hierarchical structure. This structure starts at the root of the queue hierarchy and only contains child queues for which a usage is being tracked. The hierarchy must be updated, add or delete of child entries, as part of the updates that are processed.
-
-The creation of the root queueTracker is part of the creating a new groupTracker object.
-
-```
-package user_group_manager
-
-type groupTracker struct {
- groupName string
- applications map[string]bool
- queue *queueTracker
-
- sync.RWMutex
-}
-
-newGroupTracker(queuePath string, group string) *groupTracker
-
-(gt *groupTracker) increaseResource(queuePath, applicationID string, usage *Resource)
-(gt *groupTracker) decreaseResource(queuePath, applicationID string, usage *Resource, removeApp bool)
-```
-
-### Queue tracking
-
-The queueTracker acts as a base for both user and group tracking. It provides the actual location for the tracked usage.The top of the structure, which is referenced from the userTracker or groupTracker objects, contains the root queue usage. The queueTracker is only referenced by one userTracker or one groupTracker object and must not be shared. This means that we should not require any locking within the queueTracker object.
-
-The queue hierarchy below the root, for which a usage is registered, is part of the childQueues. Each part of the full queue path creates a new level of objects. This structure shows a sparse hierarchical queue structure. It may not represent the full queue structure as known in the scheduler.
-
-The creation of the root queueTracker returns a plain object without usage set and a fixed queueName of "root". The usage should then be updated by a call to _increaseResource_. The call must handle the recursive creation of the queue path as given. It expects an applicationID to be set to a non-empty value for each call.
-
-To simply decrease the resources tracked for the queue the applicationID can be empty. On removal of the last allocation for the application the application will be removed from the queueTracker. To remove a running application from the queueTracker the applicationID must be set in the _decreaseResource_ call and the flag removeApp must be set to true.
-
-```
-package user_group_manager
-
-type queueTracker struct {
- queueName string
- resourceUsage *Resource
- runningApplications map[string]boolean
-
- childQueues map[string]*queueTracker
-}
-
-newQueueTracker() *queueTracker
-
-(qt *queueTracker) increaseResource(queuePath, applicationID string, usage *Resource)
-(qt *queueTracker) decreaseResource(queuePath, applicationID string, usage *Resource, removeApp bool)
-```
-
-### Update consistency
-
-All changes are triggered against a userTracker object. Since enforcement of a quota is out of scope of this design we can ignore update failures due to quota exhaustion. There is no requirement or possibility that updates need to be rolled back.
-
-Usage updates can be triggered from two points: allocation by the scheduler and releases by a shim. Allocations as well as releases need to update both user and group usage information. We must guarantee that for both the full hierarchy is changed or neither are changed.
-
-The releases are also processed asynchronously from the scheduling cycle. This means that we have to be able to guarantee that the increases and decreases are applied consistently to both objects also. Locking of the objects to serialise changes must be in place to support this.
-
-The other point is the update ordering and locking. The increase and decrease processing must follow the same order. Both must update the userTracker and related groupTracker objects in the same order. This is a requirement to prevent the processing of being able to deadlock while updating the same user for a simultaneous increase and decrease.
-
-For groupTracker updates that originate from two different users the locking of the groupTracker object is required. One of the two updates will be able to proceed while the other waits for the update to finalise.
-
-A final consideration is the consistency of two updates on the same object that follow each other closely. If the first update removes all existing usage the userTracker or groupTracker object is cleared for removal. While the update is in progress a second update comes in to add a new usage to the same object. The resolution of the userTracker in the user group manager has finished. The code has a reference to the object. Processing is waiting to lock the userTracker object. This point [...]
-
-### Exposure of usage tracking
-
-The usage tracking information that is part of the user group manager must be exposed for external consumption. All our current information is exposed via a REST call.
-
-Based on the current REST api definition for other object the proposal is to expose the following new endpoints:
-
-- /ws/v1/partition/\{partitionName\}/usage/users
-- /ws/v1/partition/\{partitionName\}/usage/groups
-
-For both endpoints we expose the full queue hierarchy. As an example below the approximate output for the user's endpoint for one user:
-
-```json
-[
- {
- "userName": "user1",
- "groups": {
- "app2": "tester"
- },
- "queues":
- {
- "queuename": "root",
- "resourceUsage": {
- "memory": 12000000000,
- "vcore": 12000
- },
- "runningApplications": ["app1", "app2"],
- "children": [
- {
- "queuename": "root.default",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": ["app1"],
- "children": []
- },
- {
- "queuename": "root.test",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": [
- "app2"
- ],
- "children": []
- }]
- }
- }
-]
-```
-
-
-An example below the approximate output for the groups endpoint for one group:
-
-```json
-[
- {
- "groupName" : "tester",
- "applications": ["app2"],
- "queues":
- {
- "queuename": "root",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": ["app2"],
- "children": [
- {
- "queuename": "root.test",
- "resourceUsage": {
- "memory": 6000000000,
- "vcore": 6000
- },
- "runningApplications": ["app2"],
- "children": []
- }
- ]
- }
- }
-]
-```
\ No newline at end of file
diff --git a/versioned_docs/version-1.5.0/developer_guide/build.md b/versioned_docs/version-1.5.0/developer_guide/build.md
deleted file mode 100644
index 55f71e895a..0000000000
--- a/versioned_docs/version-1.5.0/developer_guide/build.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-id: build
-title: Build and Run
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-YuniKorn always works with a container orchestrator system. Currently, a
-Kubernetes shim ([yunikorn-k8shim](https://github.com/apache/yunikorn-k8shim))
-is provided which provides a drop-in scheduler for the Kubernetes platform.
-This document describes how to setup and use a local development environment.
-
-## Dev Environment setup
-
-Read the [Dev Environment Setup](developer_guide/env_setup.md) guide first to
-setup Docker and Kubernetes development environment.
-
-## Build YuniKorn
-
-Prerequisites:
-- Golang: check the `.go_version` file in the root of the repositories for the
-version Yunikorn requires. The minimum version can change per release branch.
-Using earlier Go versions will cause compilation issues.
-
-You can build the scheduler for Kubernetes from the [yunikorn-k8shim](https://github.com/apache/yunikorn-k8shim)
-project. The build procedure will build all components into a single executable
-that can be deployed and running on Kubernetes.
-
-Start the integrated build process by pulling the `yunikorn-k8shim` repository:
-```bash
-mkdir $HOME/yunikorn/
-cd $HOME/yunikorn/
-git clone https://github.com/apache/yunikorn-k8shim.git
-```
-
-At this point you have an environment that will allow you to build an
-integrated image for the YuniKorn scheduler.
-
-### Build Docker images
-
-Building the Docker images can be triggered by following command:
-```shell script
-make image
-```
-
-This will generate images for the scheduler, scheduler plugin, and admission
-controller.
-
-The images created can be deployed directly on Kubernetes.
-Some sample deployments that can be used are found under the
-[deployments/scheduler](https://github.com/apache/yunikorn-k8shim/tree/master/deployments/scheduler)
-directory of the `yunikorn-k8shim` repository. Alternatively, the Helm charts
-located within the [helm-charts](https://github.com/apache/yunikorn-release/tree/master/helm-charts)
-directory of the `yunikorn-release` repository may be used. These match what is used
-for release builds.
-
-The configuration of YuniKorn can be customized via a ConfigMap as explained in the
-[scheduler configuration deployment](developer_guide/deployment.md) document.
-
-The `make image` build command will first build the integrated executables and
-then create the docker images. If you want to use pre-built images based on an
-offical release, please check the [Docker Hub repo](https://hub.docker.com/r/apache/yunikorn).
-
-The default image tags are not suitable for deployments to a private
-repository as these would attempt to push to Docker Hub without proper
-credentials. You *must* update the `REGISTRY` variable in the `Makefile` to
-push to an accessible repository. When you update the image tag be aware that
-the deployment examples given will also need to be updated to reflect the same
-change.
-
-### Inspect Docker images
-
-The Docker images built from previous step have embedded some important build
-info in the image metadata. You can retrieve this information with docker
-`inspect` command:
-
-```shell script
-docker inspect apache/yunikorn:scheduler-amd64-latest
-docker inspect apache/yunikorn:scheduler-plugin-amd64-latest
-docker inspect apache/yunikorn:admission-controller-amd64-latest
-```
-
-The `amd64` tag is dependent on your host architecture (i.e. for Intel it would
-be `amd64` and for Mac M1, it would be `arm64`).
-
-This info includes git revisions (last commit SHA) for each component, to help
-you understand which version of the source code was shipped by this image. They
-are listed as docker image `labels`, such as
-
-```json
-"Labels": {
- "BuildTimeStamp": "2019-07-16T23:08:06+0800",
- "Version": "0.1",
- "yunikorn-core-revision": "dca66c7e5a9e",
- "yunikorn-k8shim-revision": "bed60f720b28",
- "yunikorn-scheduler-interface-revision": "3df392eded1f"
-}
-```
-
-### Dependencies
-
-The dependencies in the projects are managed using
-[go modules](https://blog.golang.org/using-go-modules).
-
-If you want to modify one of the projects locally and build with your local
-dependencies you will need to change the module file. Changing dependencies
-requires using `go.mod` `replace` directives as explained in the
-[Update dependencies](#updating-dependencies) section.
-
-The YuniKorn project has four code repositories:
- - [yunikorn-scheduler-interface](https://github.com/apache/yunikorn-scheduler-interface)
- (protobuf interface between core and shim)
- - [yunikorn-core](https://github.com/apache/yunikorn-core)
- (core scheduler logic)
- - [yunikorn-k8shim](https://github.com/apache/yunikorn-k8shim)
- (Kubernetes-specific shim)
- - [yunikorn-web](https://github.com/apache/yunikorn-web)
- (YuniKorn Web UI)
-
-Each of these dependencies is a Go module and there are dependencies between
-them. During the development cycle it can be required to break the dependency
-on the committed version from github. This requires making changes in the module
-file to allow loading a local copy or a forked copy from a different repository.
-
-Additionally, there are two additional auxiliary repositories:
- - [yunikorn-release](https://github.com/apache/yunikorn-release)
- (release management scripts and official Helm charts)
- - [yunikorn-site](https://github.com/apache/yunikorn-site)
- (source of the yunikorn.apache.org web site)
-
-#### Affected repositories
-The following dependencies exist between the repositories:
-
-| Repository | Depends on |
-|------------------------------|---------------------------------------------|
-| yunikorn-core | yunikorn-scheduler-interface |
-| yunikorn-k8shim | yunikorn-scheduler-interface, yunikorn-core |
-| yunikorn-scheduler-interface | none |
-| yunikorn-web | none |
-
-The `yunikorn-web` repository has no direct go dependency on the other
-repositories. However any change to the `yunikorn-core` web services can affect
-the web interface.
-
-#### Making local changes
-
-To make sure that the local changes will not break other parts of the
-build you should run:
-- A full build `make` (build target depends on the repository)
-- A full unit test run `make test`
-
-Any test failures should be fixed before proceeding.
-
-#### Updating dependencies
-
-The simplest way is to use the `replace` directive in the module file.
-The `replace` directive allows you to override the import path with a new
-(local) path. There is no need to change any of the imports in the source code.
-The change must be made in the `go.mod` file of the repository that has the
-dependency.
-
-Using `replace` to use of a forked dependency, such as:
-```
-replace github.com/apache/yunikorn-core => example.com/some/forked-yunikorn
-```
-
-There is no requirement to fork and create a new repository. If you do not have
-a repository you can use a local checked out copy too.
-
-Using `replace` to use of a local directory as a dependency:
-```
-replace github.com/apache/yunikorn-core => /User/example/local/checked-out-yunikorn
-```
-
-For the same dependency using a relative path:
-```
-replace github.com/apache/yunikorn-core => ../checked-out-yunikorn
-```
-Note: if the `replace` directive is using a local filesystem path, then the target
-must have a `go.mod` file at that location.
-
-Further details can be found on the Go Wiki:
-[When should I use the 'replace' directive?](https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive)
-
-## Build the Web UI
-
-Example deployments reference the
-[YuniKorn Web UI](https://github.com/apache/yunikorn-web). The `yunikorn-web`
-project has specific requirements for the build. Follow the steps in the
-[README](https://github.com/apache/yunikorn-web/blob/master/README.md) to prepare
-a development environment and build the Web UI. However, the scheduler is fully
-functional without the Web UI.
-
-## Run YuniKorn locally
-
-When you have a local development environment setup you can run the scheduler
-in your local Kubernetes environment. This has been tested in a desktop
-enviornment with Docker Desktop, Minikube, and Kind. See the
-[Dev Environment Setup](developer_guide/env_setup.md) guide for further details.
-
-To run a local instance of the scheduler:
-
-```shell script
-make run
-```
-
-This will launch a local scheduler and connect to the Kubernetes cluster
-referenced in your `KUBECONFIG` or `$HOME/.kube/config`.
-
-To run YuniKorn in Kubernetes scheduler plugin mode instead, execute:
-
-```
-make run_plugin
-```
-
-You can also use the same approach to run the scheduler locally but connecting
-to a remote kubernetes cluster, as long as the `$HOME/.kube/config` file
-is pointing to that remote cluster.
-
-## Run end-to-end tests
-
-In addition to the unit tests for each project, YuniKorn contains many e2e
-(end-to-end) tests in the `yunikorn-k8shim` repository which validate
-functionaliy of the scheduler on a functioning Kubernetes cluster.
-
-How to run the tests locally is described
-[here](https://github.com/apache/yunikorn-k8shim/blob/master/test/e2e/README.md).
diff --git a/versioned_docs/version-1.5.0/developer_guide/dependencies.md b/versioned_docs/version-1.5.0/developer_guide/dependencies.md
deleted file mode 100644
index d458798df2..0000000000
--- a/versioned_docs/version-1.5.0/developer_guide/dependencies.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-id: dependencies
-title: Go module updates
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## When to update
-The references in the `master` branches must be updated if a change is made in the scheduler interface.
-Updating the dependency of a shim in reference to the core might be needed even if the scheduler interface does not change.
-New functionality could be added that rely on changed field content of the messages, not the field layout of the message.
-In that case just the shim dependency needs to be updated.
-
-## Why a pseudo version
-In the `master` branch we **must** use a pseudo version for all the YuniKorn repository references we use.
-As the branch is in active development and not released we do not have a real version tag to reference.
-However, we still need to be able to point to the right commit for the dependencies.
-
-Go allows using [pseudo versions](https://go.dev/ref/mod#pseudo-versions) for these specific cases.
-An example of the pseudo versions we use in the Kubernetes shim:
-```
-module github.com/apache/yunikorn-k8shim
-
-go 1.16
-
-require (
- github.com/apache/yunikorn-core v0.0.0-20220325135453-73d55282f052
- github.com/apache/yunikorn-scheduler-interface v0.0.0-20220325134135-4a644b388bc4
- ...
-)
-```
-Release branches **must** not use pseudo versions.
-During the creation of a release, [tags](/community/release_procedure#tag-and-update-release-for-version) will be created.
-These tags will be used as the reference in the go.mod files for the release.
-
-## Enforcement of pseudo version
-In the pull request checks for the `yunikorn-core` and `yunikorn-k8shim` repositories enforce the format of the versions.
-A build failure will be triggered if the version reference for the `yunikorn-core` or `yunikorn-scheduler-interface`
-repositories in the `master` branch is not a pseudo version.
-
-The check enforces that the start of the version reference is `v.0.0.0-`
-
-Pseudo versions are not enforced in the release branches as per [why a pseudo version](#why-a-pseudo-version) explanation above.
-
-## Updating the core dependency
-Before updating the core dependency must make sure that the scheduler interface changes are finalised.
-
-1. Make the changes in the scheduler interface.
-2. Commit the changes into the master branch on GitHub and pull the latest master branch commit.
-3. [Generate a new pseudo version](#generating-a-pseudo-version) for the scheduler-interface.
-
-Updating the core dependency
-
-4. Update the go.mod file for the dependent repository: core repository
- * Open the go.mod file
- * Copy the generated pseudo version reference
- * Replace the scheduler-interface version reference with the one generated in step 3.
- * Save the go.mod file
-5. Run a `make test` to be sure that the change works. The build will pull down the new dependency and the change in the scheduler interface will be used.
-6. Commit the changes into the master branch on GitHub and pull the latest master branch commit
-
-## Updating a shim dependency
-Before updating a shim dependency you must make sure that the core dependency has been updated and committed.
-There are cases that the reference for the scheduler-interface has not changed.
-This is not an issue, either skip the update steps or execute them as per normal resulting in no changes as part of the commit.
-
-7. [Generate a new pseudo version](#generating-a-pseudo-version) for the core
-8. Update the go.mod file for the dependent repository: k8shim repository
- * Open the go.mod file
- * Copy the generated pseudo version reference of the scheduler interface
- * Replace the scheduler-interface version reference with the one generated in step 3.
- * Copy the generated pseudo version reference of the core
- * Replace the core version reference with the one generated in step 7.
- * Save the go.mod file
-9. Run a `make test` to be sure that the change works. The build will pull down the new dependency and the changes in the core and scheduler interface will be used.
-10. Commit the changes into the master branch on GitHub
-
-:::note
-If multiple PRs are being worked on in the scheduler interface and or core at the same time a different PR might have already applied the update.
-This will all depend on the commit order.
-It is therefor that steps 5 and 8 are performed to make sure there is no regression.
-:::
-## Generating a pseudo version
-
-A pseudo references for use in a go.mod file is based on the commit hash and timestamp.
-It is simple to generate one using the following steps:
-
-1. Change to the repository for which the new pseudo version needs to be generated.
-2. Update the local checked out code for the master branch to get the latest commits
-```
-git pull; git status
-```
-The status should show up to date with the `origin` from where it was cloned.
-3. Run the following command to get the pseudo version:
-```
-TZ=UTC git --no-pager show --quiet --abbrev=12 --date='format-local:%Y%m%d%H%M%S' --format='v0.0.0-%cd-%h'
-```
-4. This command will print a line like this:
-```
-v0.0.0-20220318052402-b3dfd0d2adaa
-```
-That is the pseudo version that can be used in the go.mod files.
-
-:::note
-The pseudo version must be based on a commit that is in the vcs system, i.e. from Github.
-Local commits or commits that are not yet merged in a PR cannot be used.
-:::
diff --git a/versioned_docs/version-1.5.0/developer_guide/deployment.md b/versioned_docs/version-1.5.0/developer_guide/deployment.md
deleted file mode 100644
index 2a098e25d9..0000000000
--- a/versioned_docs/version-1.5.0/developer_guide/deployment.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-id: deployment
-title: Deploy to Kubernetes
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-The easiest way to deploy YuniKorn is to leverage our [helm charts](https://hub.helm.sh/charts/yunikorn/yunikorn),
-you can find the guide [here](get_started/get_started.md). This document describes the manual process to deploy YuniKorn
-scheduler and admission controller. It is primarily intended for developers.
-
-**Note** The primary source of deployment information is the Helm chart, which can be found at [yunikorn-release](https://github.com/apache/yunikorn-release/). Manual deployment may lead to out-of-sync configurations, see [deployments/scheduler](https://github.com/apache/yunikorn-k8shim/tree/master/deployments/scheduler)
-
-## Build docker image
-
-Under project root of the `yunikorn-k8shim`, run the command to build an image using the map for the configuration:
-```
-make image
-```
-
-This command will build an image. The image will be tagged with a default version, image tag and your build architecture.
-
-**Note** the default build uses a hardcoded user and tag. You *must* update the `IMAGE_TAG` variable in the `Makefile` to push to an appropriate repository.
-
-**Note** the latest yunikorn images in docker hub are not updated anymore due to ASF policy. Hence, you should build both scheduler image and web image locally before deploying them.
-
-**Note** the imaging tagging includes your build architecture. For Intel, it would be `amd64` and for Mac M1, it would be `arm64`.
-
-## Setup RBAC for Scheduler
-In the example, RBAC are configured for the yuniKorn namespace.
-The first step is to create the RBAC role for the scheduler, see [yunikorn-rbac.yaml](https://github.com/apache/yunikorn-k8shim/blob/master/deployments/scheduler/yunikorn-rbac.yaml)
-```
-kubectl create -f deployments/scheduler/yunikorn-rbac.yaml
-```
-The role is a requirement on the current versions of kubernetes.
-
-## Create/Update the ConfigMap
-
-This must be done before deploying the scheduler. It requires a correctly setup kubernetes environment.
-This kubernetes environment can be either local or remote.
-
-- download configuration file if not available on the node to add to kubernetes:
-```
-curl -o yunikorn-configs.yaml https://raw.githubusercontent.com/apache/yunikorn-k8shim/master/deployments/scheduler/yunikorn-configs.yaml
-```
-- modify the content of yunikorn-configs.yaml file as needed, and create ConfigMap in kubernetes:
-```
-kubectl create configmap yunikorn-configs --from-file=yunikorn-configs.yaml
-```
-- Or update ConfigMap in kubernetes:
-```
-kubectl create configmap yunikorn-configs --from-file=yunikorn-configs.yaml -o yaml --dry-run=client | kubectl apply -f -
-```
-- check if the ConfigMap was created/updated correctly:
-```
-kubectl describe configmaps yunikorn-configs
-```
-
-## Deploy the Scheduler
-
-The scheduler can be deployed with following command.
-```
-kubectl create -f deployments/scheduler/scheduler.yaml
-```
-
-The deployment will run 2 containers from your pre-built docker images in 1 pod,
-
-* yunikorn-scheduler-core (yunikorn scheduler core and shim for K8s)
-* yunikorn-scheduler-web (web UI)
-
-Alternatively, the scheduler can be deployed as a K8S scheduler plugin:
-```
-kubectl create -f deployments/scheduler/plugin.yaml
-```
-
-The pod is deployed as a customized scheduler, it will take the responsibility to schedule pods which explicitly specifies `schedulerName: yunikorn` in pod's spec. In addition to the `schedulerName`, you will also have to add a label `applicationId` to the pod.
-```yaml
- metadata:
- name: pod_example
- labels:
- applicationId: appID
- spec:
- schedulerName: yunikorn
-```
-
-Note: Admission controller abstracts the addition of `schedulerName` and `applicationId` from the user and hence, routes all traffic to YuniKorn. If you use helm chart to deploy, it will install admission controller along with the scheduler. Otherwise, proceed to the steps below to manually deploy the admission controller if running non-example workloads where `schedulerName` and `applicationId` are not present in the pod spec and metadata, respectively.
-
-
-## Setup RBAC for Admission Controller
-
-Before the admission controller is deployed, we must create its RBAC role, see [admission-controller-rbac.yaml](https://github.com/apache/yunikorn-k8shim/blob/master/deployments/scheduler/admission-controller-rbac.yaml).
-
-```
-kubectl create -f deployments/scheduler/admission-controller-rbac.yaml
-```
-
-## Create the Secret
-
-Since the admission controller intercepts calls to the API server to validate/mutate incoming requests, we must deploy an empty secret
-used by the webhook server to store TLS certificates and keys. See [admission-controller-secrets.yaml](https://github.com/apache/yunikorn-k8shim/blob/master/deployments/scheduler/admission-controller-secrets.yaml).
-
-```
-kubectl create -f deployments/scheduler/admission-controller-secrets.yaml
-```
-
-## Deploy the Admission Controller
-
-Now we can deploy the admission controller as a service. This will automatically validate/modify incoming requests and objects, respectively, in accordance with the [example in Deploy the Scheduler](#Deploy-the-Scheduler). See the contents of the admission controller deployment and service in [admission-controller.yaml](https://github.com/apache/yunikorn-k8shim/blob/master/deployments/scheduler/admission-controller.yaml).
-
-```
-kubectl create -f deployments/scheduler/admission-controller.yaml
-```
-
-## Access to the web UI
-
-When the scheduler is deployed, the web UI is also deployed in a container.
-Port forwarding for the web interface on the standard ports can be turned on via:
-
-```
-kubectl port-forward svc/yunikorn-service 9889 9080
-```
-
-`9889` is the default port for Web UI, `9080` is the default port of scheduler's Restful service where web UI retrieves info from.
-Once this is done, web UI will be available at: http://localhost:9889.
-
-## Configuration Hot Refresh
-
-YuniKorn uses config maps for configurations, and it supports loading configuration changes automatically by watching config map changes using shared informers.
-
-To make configuration changes, simply update the content in the configmap, which can be done either via Kubernetes dashboard UI or command line. Note, changes made to the configmap might have some delay to be picked up by the scheduler.
-
diff --git a/versioned_docs/version-1.5.0/developer_guide/env_setup.md b/versioned_docs/version-1.5.0/developer_guide/env_setup.md
deleted file mode 100644
index ee5b4df8c5..0000000000
--- a/versioned_docs/version-1.5.0/developer_guide/env_setup.md
+++ /dev/null
@@ -1,299 +0,0 @@
----
-id: env_setup
-title: Dev Environment Setup
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-There are several ways to setup a local development environment for Kubernetes.
-The three most common ones are **Minikube** ([docs](https://kubernetes.io/docs/setup/minikube/)),
-**Docker Desktop** and **Kind** ([docs](https://kind.sigs.k8s.io/)).
-**Minikube** provisions a local Kubernetes cluster on several Virtual Machines
-(via VirtualBox or something similar).
-
-**Docker Desktop**, on the other hand, sets up Kubernetes cluster using a local
-Docker installation.
-
-**Kind** provides lightweight Kubernetes clusters for Windows, Linux and Mac
-using an existing Docker installation.
-
-## Local Kubernetes cluster using Docker Desktop
-
-In this tutorial, we will base all the installs on Docker Desktop.
-Even in this case we can use a lightweight [minikube](#local-kubernetes-cluster-with-minikube)
-setup which gives the same functionality with less impact.
-
-### Installation
-
-Download and install [Docker Desktop](https://www.docker.com/products/docker-desktop).
-Newer Docker versions have an embedded version of Kubernetes so no additional
-installation is needed. Follow the instructions [here](https://docs.docker.com/desktop/kubernetes/#install-and-turn-on-kubernetes)
-to get Kubernetes up and running within Docker Desktop.
-Alternatively, a Kind cluster may be created (see instructions
-[here](https://kind.sigs.k8s.io/docs/user/quick-start/#creating-a-cluster).
-
-Once Kubernetes is started in Docker Desktop, you should see something similar
-to this:
-
-
-
-This means that:
-
-1. Kubernetes is running.
-2. The command line tool `kubectl` is installed in the `/usr/local/bin` directory.
-3. The Kubernetes context is set to `docker-desktop`.
-
-### Deploy and access dashboard
-
-Optionally, after setting up Kubernetes you may wish to deploy the Kubernetes
-Dashboard Web UI. The dashboard may be deployed using the following steps:
-
-1. Follow the instructions [here](https://github.com/kubernetes/dashboard) to deploy the dashboard.
-2. Start the Kubernetes proxy in the background from a terminal to get access on the dashboard on the local host:
- ```shell script
- kubectl proxy &
- ```
-3. Access the dashboard [here](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard-kong-proxy:443/proxy/#/login).
-
-### Access local Kubernetes cluster
-
-The dashboard as deployed in the previous step requires a token or config to
-sign in. Here we use the token to sign in. The token is generated
-automatically and can be retrieved from the system.
-
-1. Retrieve the name of the dashboard token:
- ```shell script
- kubectl -n kube-system get secret | grep kubernetes-dashboard-token
- ```
-2. Retrieve the content of the token. Note that the token name ends with a random
- 5 character code and needs to be replaced with the result of step 1. As an
- example:
- ```shell script
- kubectl -n kube-system describe secret kubernetes-dashboard-token-tf6n8
- ```
-3. Copy the token value which is part of the `Data` section with the tag `token`.
-4. Select the **Token** option in the dashboard web UI:<br/>
- 
-5. Paste the token value into the input box and sign in:<br/>
- 
-
-## Local Kubernetes cluster with Minikube
-Minikube can be added to an existing Docker Desktop install. Minikube can
-either use the pre-installed hypervisor or use a hypervisor of your choice.
-These instructions use [HyperKit](https://github.com/moby/hyperkit) which is
-embedded in Docker Desktop.
-
-If you want to use a different hypervisor then HyperKit make sure that you
-follow the generic minikube install instructions. Do not forget to install
-the correct driver for the chosen hypervisor if required. The minikube
-installation instructions can be found [here](https://kubernetes.io/docs/tasks/tools/install-minikube/).
-
-Docker Desktop should have already installed HyperKit. To verify this, open a
-terminal and run: `hyperkit`. Any response other than
-`hyperkit: command not found` confirms that HyperKit is installed and on
-the path. If it is not found you can choose a different hypervisor or
-fix the Docker Desktop install.
-
-### Installing Minikube
-1. Install minikube, either via `brew` or directly via these steps:
- ```shell script
- curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64
- chmod +x minikube
- sudo mv minikube /usr/local/bin
- ```
-2. Install HyperKit driver (required). You can either use `brew` or directly via these steps:
- ```shell script
- curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit
- sudo install -o root -g wheel -m 4755 docker-machine-driver-hyperkit /usr/local/bin/
- ```
-3. Update the minikube configuration to default to using HyperKit:
- ```shell script
- minikube config set vm-driver hyperkit
- ```
-4. Change Docker Desktop to use minikube for Kubernetes:<br/>
- 
-
-### Deploy and access the cluster
-After the installation is done you can start a new cluster.
-1. Start the minikube cluster:
- ```shell script
- minikube start --kubernetes-version v1.24.7
- ```
-2. Start the minikube dashboard:
- ```shell script
- minikube dashboard &
- ```
-
-### Build impact
-When you create images make sure that the build is run after pointing it to
-the correct cluster. Without setting the environment minikube might not find
-the docker images when deploying the scheduler.
-
-1. Make sure minikube is started.
-2. In the terminal where you will run the build, execute:
- ```shell script
- eval $(minikube docker-env)
- ```
-3. Run the image build from the yunikorn-k8shim repository root:
- ```shell script
- make image
- ```
-4. Deploy the scheduler as per the normal instructions.
-
-## Local Kubernetes Cluster with Kind
-
-Kind (Kubernetes in Docker) is a lightweight tool for running lightweight
-Kubernetes environments. It is very easy to test different Kubernetes versions
-with Kind by specifing the version during cluster setup.
-
-### Installation
-
-If you have go installed, you can run:
-```shell script
-go install sigs.k8s.io/kind@latest
-```
-
-Other installation methods can be found on the Kind
-[website](https://kind.sigs.k8s.io/docs/user/quick-start/#installation).
-
-Kind version 0.15 is required for Kubernetes 1.25 or later.
-Later versions of Kind add Kubernetes 1.26, 1.27 and 1.28.
-Check the Kind release notes for the specific Kubernetes releases supported.
-
-### Using Kind
-
-To test a new version of Kubernetes, you can pull a corresponding image from
-kind's repository.
-
-For example, to create a cluster running Kubernetes 1.26.6:
-```shell script
-kind create cluster --name test --image kindest/node:v1.26.6
-```
-
-Kind will download the appropriate image and launch a new cluster named
-`test`. The active Kubernetes cluster will also be changed to `test`.
-
-To delete the kind cluster:
-```shell script
-kind delete cluster --name test
-```
-
-### Loading your images
-
-In order to use a local image, you have to load your images into kind's
-registry. If you run `make image`, you could use the following command
-to load your kind image. This assumes AMD64 architecture.
-
-The scheduler, web-ui and admission-controller examples are below:
-
-```shell script
-kind load docker-image apache/yunikorn:scheduler-amd64-latest
-kind load docker-image apache/yunikorn:web-amd64-latest
-kind load docker-image apache/yunikorn:admission-amd64-latesta
-```
-
-If running on an ARM system, replace `amd64` with `arm64` above.
-
-## Debug code locally
-
-The scheduler may be run locally for debugging. This example assumes
-you have installed the GoLand IDE for development.
-
-In GoLand, open the `yunikorn-k8shim` project. Then click "Run" ->
-"Debug..." -> "Edit Configuration..." to get the pop-up configuration
-window. Note, you need to click "+" to create a new profile if the `Go Build`
-option is not available at the first time.
-
-
-
-Set the following values in the dialog (as shown):
-
-- Run Kind: Package
-- Package path: `github.com/apache/yunikorn-k8shim/pkg/cmd/shim`
-- Working directory: Project base directory (`yunikorn-k8shim`)
-- Program arguments: Empty
-- Environment: If `KUBECONFIG` is not set globally, ensure it is set here.
- Additionally, you may want to set `NAMESPACE=yunikorn`, as otherwise
- YuniKorn will look for the `yunikorn-configs` ConfigMap under the
- `default` Kubernetes namespace.
-
-Once the changes are done, click "Apply", then "Debug". You will need to
-set proper breakpoints in order to debug the program.
-
-## Debug the scheduler plugin
-
-The scheduler may also be run in plugin mode. In this mode, the YuniKorn
-scheduler is built on top of the default scheduler and runs as a
-plugin (rather than completely standalone). Functionally, it performs the
-same tasks, but relies on the upstream Kubernetes scheduler codebase for
-common functionality.
-
-The run configuration for the scheduler in plugin mode is as follows:
-
-- Run Kind: Package
-- Package path: `github.com/apache/yunikorn-k8shim/pkg/cmd/schedulerplugin`
-- Working directory: Project base directory (`yunikorn-k8shim`)
-- Program arguments:
- ```
- --bind-address=0.0.0.0
- --leader-elect=false
- --config=conf/scheduler-config-local.yaml
- -v=2
- ```
-- Environment: If `KUBECONFIG` is not set globally, ensure it is set here.
- Additionally, you may want to set `NAMESPACE=yunikorn`, as otherwise
- YuniKorn will look for the `yunikorn-configs` ConfigMap under the
- `default` Kubernetes namespace.
-
-Additionally, before running for the first time, run `make init` from a
-terminal in the root of the `yunikorn-k8shim` repository. This will
-generate the contents of `conf/scheduler-config-local.yaml`, which is
-required.
-
-## Access remote Kubernetes cluster
-
-This setup assumes you have already installed a remote Kubernetes cluster.
-For a generic view on how to access a multiple cluster and integrate it follow
-the [accessing multiple clusters](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
-documentation from Kubernetes.
-
-Or follow these simplified steps:
-1. Get the Kubernetes `config` file from remote cluster, copy it to the local
- machine and give it a unique name i.e. `config-remote`
-2. Save the `KUBECONFIG` environment variable (if set)
- ```shell script
- export KUBECONFIG_SAVED=$KUBECONFIG
- ```
-3. Add the new file to the environment variable
- ```shell script
- export KUBECONFIG=$KUBECONFIG:config-remote
- ```
-4. Run the command `kubectl config view` to check that both configs can be accessed
-5. Switch context using `kubectl config use-context remote-cluster`
-6. Confirm that the current context is now switched to the remote cluster config:
- ```text
- kubectl config get-contexts
- CURRENT NAME CLUSTER AUTHINFO
- docker-desktop docker-desktop-cluster docker-for-desktop
- * remote-cluster kubernetes kubernetes-admin
- ```
-
-More documentation can be found
-[here](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/).
diff --git a/versioned_docs/version-1.5.0/developer_guide/scheduler_object_states.md b/versioned_docs/version-1.5.0/developer_guide/scheduler_object_states.md
deleted file mode 100644
index 86cc135aea..0000000000
--- a/versioned_docs/version-1.5.0/developer_guide/scheduler_object_states.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-id: scheduler_object_states
-title: Scheduler Object States
----
-
-<!--
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- -->
-
-The YuniKorn project uses state machines to track the states of different objects.
-This ranges from applications in the core to nodes in the k8shim.
-The state machines are independent and not shared between the resource managers and core.
-A resource manager shim, and the core can thus have an independent idea of the state of a similar object.
-
-## Core Scheduler
-State change are triggered by events that get processed.
-One event can cause a change for multiple states or no change at all.
-
-### Application State
-Applications have a complex state model.
-An application when created starts ain the new state.
-
-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.
-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.
-This state is part of the normal scheduling cycle.
-* Completing: An application that has no pending requests or running containers/pod will be completing.
-This state shows that the application has not been marked completed yet but currently is not actively being scheduled.
-* Completed: An application is considered completed when it has been in the completing state for a defined time period.
-From this state the application can only move to the Expired state, and it cannot move back into any of scheduling states (Running or Completing)
-The current timeout is set to 30 seconds.
-* Expired: The completed application is tracked for a period of time, after that is expired and deleted from the scheduler.
-This is a final state and after this state the application cannot be tracked anymore.
-* Failing: An application marked for failing, what still has some allocations or asks what needs to be cleaned up before entering into the Failed state.
- The application can be Failing when the partition it belongs to is removed or during gang scheduling, if the placeholder processing times out, and the application has no real allocations yet.
-* Failed: An application is considered failed when it was marked for failure and all the pending requests and allocations were already removed.
-From this state the application can only move to the Expired state.
-* Rejected: The application was rejected when it was added to the scheduler.
-This only happens when a resource manager tries to add a new application, when it gets created in a New state, and the scheduler rejects the creation.
-Applications can be rejected due ACLs denying access to a queue the application has specified, or a placement via placement rules has failed. From this state the application can only move to the Expired state.
-
-The events that can trigger a state change:
-* Reject: rejecting the application by the scheduler (source: core scheduler)
-* Run: progress an application to the next active state (source: core scheduler)
-* Complete: mark an application as idle or complete (source: core scheduler)
-* Fail: fail an application (source: resource manager or core scheduler)
-* Expire: progress the application to the expired state and remove it from the scheduler (source: core scheduler)
-
-Here is a diagram that shows the states with the event that causes the state to change:
-
-
-### Object State
-<!-- fix the draining to stopped transition -->
-The object state is used by the following objects:
-* queues
-* partitions
-
-The object states are as follows:
-* Active: The object is active and used during the scheduling cycle.
-This is the starting and normal state of an object.
-An active object transitions to draining when it is removed.
-* Stopped: The object is stopped and no longer actively scheduled.
-The object if empty is ready to be removed from the scheduler.
-The object can transition back into active state if it gets re-started.
-* Draining: Before an object can be removed it needs to be cleaned up.
-The cleanup starts with placing the object in the draining state.
-In this state it does not accept additions or changes but is still actively being scheduled.
-This allows for a graceful shutdown, cleanup and removal of the object.
-This is the final state.
-
-The events that can trigger a state change:
-* Start: make the object active (source: core scheduler)
-* Stop: make the object inactive (source: core scheduler)
-* Remove: mark an object for removal (source: core scheduler)
-
-Here is a diagram that shows the states with the event that causes the state to change:
-
-
-### Node
-<!-- should start using object state -->
-Node objects in the core are not using a state machine but do have a state.
-A node can have one of two states: `schedulable` or `not schedulable`.
-There is no complex state model or complex transition logic.
-The scheduler can either use the node or not.
-
-The node status changes based on the status provided by the resource manager (shim) that owns the node.
-
-## K8Shim Resource Manager
-
-### Application
-
-
-### Task
-
-
-### Node
-
diff --git a/versioned_docs/version-1.5.0/get_started/core_features.md b/versioned_docs/version-1.5.0/get_started/core_features.md
deleted file mode 100644
index ca9f701201..0000000000
--- a/versioned_docs/version-1.5.0/get_started/core_features.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-id: core_features
-title: Features
-keywords:
- - feature
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-The main features of YuniKorn include:
-
-## App-aware scheduling
-One of the key differences of YuniKorn is that it does app-aware scheduling. The default K8s scheduler simply schedules
-pod by pod without any context about user, app, or queue. However, YuniKorn recognizes users, apps, and queues, and it considers
-a lot more factors, e.g resource, ordering etc, while making scheduling decisions. This gives us the possibility to use
-fine-grained controls on resource quotas, resource fairness, and priorities, which are the most important requirements
-for a multi-tenancy computing system.
-
-## Hierarchy Resource Queues
-Hierarchy queues provide an efficient mechanism to manage cluster resources. The hierarchy of the queues can logically
-map to the structure of an organization. This gives fine-grained control over resources for different tenants. The YuniKorn
-UI provides a centralised view to monitor the usage of resource queues and helps you to gain insight into how the resources are
-used across different tenants. What's more, by leveraging the min/max queue capacity, it can define how elastic it can be
-in terms of the resource consumption for each tenant.
-
-## Gang Scheduling
-An application can request a set of resources, i.e. a gang, to be scheduled all at once.
-The gang defines all the resources the application requires to start.
-During the first scheduling phase all resources requested will be reserved.
-The application will only be started when all requested resources are available.
-
-Reservation duration and application behaviour when the reservation fails are configurable.
-It is even possible to create multiple gangs of different specifications for one application.
-See the [gang design](design/gang_scheduling.md) and the Gang Scheduling [user guide](user_guide/gang_scheduling.md) for more details.
-
-## Job Ordering and Queuing
-Applications can be properly queued in working-queues, the ordering policy determining which application can get resources first.
-There are various policies such as simple `FIFO`, `Fair`, `StateAware`, or `Priority` based. Queues can maintain the order of applications,
-and based on different policies, the scheduler allocates resources to jobs accordingly. The behavior is much more predictable.
-
-What's more, when the queue max-capacity is configured, jobs and tasks can be properly queued up in the resource queue.
-If the remaining capacity is not enough, they can be waiting in line until some resources are released. This simplifies
-the client side operation. Unlike the default scheduler, resources are capped by namespace resource quotas which
-are enforced by the quota-admission-controller. If the underlying namespace does not have enough quota, pods cannot be
-created. Client side needs complex logic, e.g retry by condition, to handle such scenarios.
-
-## Resource fairness
-In a multi-tenant environment, a lot of users share cluster resources. To prevent tenants from competing for resources
-and potentially getting starved, more fine-grained fairness controls are needed to achieve fairness across users, as well as across teams/organizations.
-With consideration of weights or priorities, more important applications can demand resources beyond their share.
-This feature is often considered in relation to resource budgets, where a more fine-grained fairness mode can further improve spending efficiency.
-
-## Resource Reservation
-YuniKorn automatically does reservations for outstanding requests. If a pod could not be allocated, YuniKorn will try to
-reserve it on a qualified node and tentatively allocate the pod on this reserved node (before trying rest of nodes).
-This mechanism can prevent the pod from being starved by future smaller, less-picky pods.
-This feature is important in the batch workloads scenario because when a large amount of heterogeneous pods are submitted
-to the cluster, it's very likely some pods can be starved even when they are submitted much earlier.
-
-## Preemption
-YuniKorn's preemption feature allows higher-priority tasks to dynamically reallocate resources by preempting lower-priority ones, ensuring critical workloads get necessary resources in a multi-tenant Kubernetes environment.
-This proactive mechanism maintains system stability and fairness, integrating with Kubernetes' priority classes and YuniKorn's hierarchical queue system.
-
-## Throughput
-Throughput is a key criterion for measuring scheduler performance. It is critical for a large scale distributed system.
-If throughput is bad, applications may waste time on waiting for scheduling and further impact service SLAs.
-When the cluster gets bigger, it also means there is a requirement for higher throughput. The [performance evaluation based on Kube-mark](performance/evaluate_perf_function_with_kubemark.md)
-reveals some perf numbers.
-
-## MaxApplication Enforcement
-The MaxApplication enforcement feature allows users to limit the number of running applications for a configured queue.
-This feature is critical in large scale batch workloads.
-Without this feature, when a large number of concurrent jobs are launched, they would compete for resources, and a certain amount of resources would be wasted, which could lead to job failure.
-The [Partition and Queue Configuration](user_guide/queue_config.md) provides configuration examples.
-
-## CPU Architecture support
-YuniKorn supports running on ARM as well as on AMD/Intel CPUs.
-With the release of YuniKorn 1.1.0, prebuilt convenience images for both architectures are provided in docker hub.
diff --git a/versioned_docs/version-1.5.0/get_started/get_started.md b/versioned_docs/version-1.5.0/get_started/get_started.md
deleted file mode 100644
index 2accf66ef4..0000000000
--- a/versioned_docs/version-1.5.0/get_started/get_started.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-id: user_guide
-title: Get Started
-slug: /
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-Before reading this guide, we assume you either have a Kubernetes cluster, or a local Kubernetes dev environment, e.g MiniKube.
-It is also assumed that `kubectl` is on your path and properly configured.
-Follow this [guide](developer_guide/env_setup.md) on how to setup a local Kubernetes cluster using docker-desktop.
-
-## Install
-
-The easiest way to get started is to use our Helm Charts to deploy YuniKorn on an existing Kubernetes cluster.
-It is recommended to use Helm 3 or later versions.
-
-```shell script
-helm repo add yunikorn https://apache.github.io/yunikorn-release
-helm repo update
-kubectl create namespace yunikorn
-helm install yunikorn yunikorn/yunikorn --namespace yunikorn
-```
-
-By default, the helm chart will install the scheduler, web-server and the admission-controller in the cluster.
-When `admission-controller` is installed, it simply routes all traffic to YuniKorn. That means the resource scheduling
-is delegated to YuniKorn. You can disable it by setting `embedAdmissionController` flag to `false` during the helm install.
-
-The YuniKorn scheduler can also be deployed as a Kubernetes scheduler plugin by setting the Helm `enableSchedulerPlugin`
-flag to `true`. This will deploy an alternate Docker image which contains YuniKorn compiled together with the default
-scheduler. This new mode offers better compatibility with the default Kubernetes scheduler and is suitable for use with the
-admission controller delegating all scheduling to YuniKorn. Because this mode is still very new, it is not enabled by default.
-
-If you are unsure which deployment mode you should use, refer to our [side-by-side comparison](user_guide/deployment_modes).
-
-Further configuration options for installing YuniKorn via Helm are available in the [YuniKorn Helm hub page](https://hub.helm.sh/charts/yunikorn/yunikorn).
-
-If you don't want to use helm charts, you can find our step-by-step
-tutorial [here](developer_guide/deployment.md).
-
-## Uninstall
-
-Run the following command to uninstall YuniKorn:
-```shell script
-helm uninstall yunikorn --namespace yunikorn
-```
-
-## Access the Web UI
-
-When the scheduler is deployed, the web UI is also deployed in a container.
-Port forwarding for the web interface on the standard port can be turned on via:
-
-```
-kubectl port-forward svc/yunikorn-service 9889:9889 -n yunikorn
-```
-
-`9889` is the default port for web UI.
-Once this is done, web UI will be available at: `http://localhost:9889`.
-
-
-
-YuniKorn UI provides a centralised view for cluster resource capacity, utilization, and all application info.
-
-Besides, YuniKorn also exposes its scheduling metrics via Prometheus.
-
-If you want to monitor the yunikorn core services by using Prometheus and Grafana, you can find our step-by-step tutorial [here](../user_guide/prometheus.md).
\ No newline at end of file
diff --git a/versioned_docs/version-1.5.0/get_started/version.md b/versioned_docs/version-1.5.0/get_started/version.md
deleted file mode 100644
index 9ec67bbe62..0000000000
--- a/versioned_docs/version-1.5.0/get_started/version.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-id: version
-title: Version details
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Which version should be used?
-
-The recommendation is to always run the latest possible version of YuniKorn.
-New releases are made regular driven by new features for YuniKorn itself and or the shim.
-Features and fixes are currently only added to the development branch from which releases are cut.
-
-At this point in time the project only creates minor releases, no patch releases.
-
-If a shim version, i.e. Kubernetes, is supported by multiple YuniKorn releases we recommend to always use the latest YuniKorn release possible.
-Older build dependencies in earlier releases could prevent you from using some new functionality exposed by a newer shim.
-
-# Kubernetes versions supported by YuniKorn
-
-| K8s Version | Supported <br/>from version | Support ended |
-|---------------------|:---------------------------:|:-------------:|
-| 1.12.x (or earlier) | - | - |
-| 1.13.x | 0.8.0 | 0.10.0 |
-| 1.14.x | 0.8.0 | 0.10.0 |
-| 1.15.x | 0.8.0 | 0.10.0 |
-| 1.16.x | 0.10.0 | 0.11.0 |
-| 1.17.x | 0.10.0 | 0.11.0 |
-| 1.18.x | 0.10.0 | 0.11.0 |
-| 1.19.x | 0.11.0 | 1.0.0 |
-| 1.20.x | 0.12.1 | 1.2.0 |
-| 1.21.x | 0.12.1 | 1.3.0 |
-| 1.22.x | 0.12.2 | 1.3.0 |
-| 1.23.x | 0.12.2 | 1.3.0 |
-| 1.24.x | 1.0.0 | - |
-| 1.25.x | 1.2.0 | - |
-| 1.26.x | 1.2.0 | - |
-| 1.27.x | 1.4.0 | - |
-| 1.28.x | 1.4.0 | - |
-| 1.29.x | 1.5.0 | - |
-
diff --git a/versioned_docs/version-1.5.0/metrics/queue.md b/versioned_docs/version-1.5.0/metrics/queue.md
deleted file mode 100644
index 4943fd3092..0000000000
--- a/versioned_docs/version-1.5.0/metrics/queue.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-id: queue
-title: Queue
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Application
-Each queue has a `<queue_name> queue_app` metric to trace the applications in the queue.
-`<queue_name> queue_app` metrics records the number of applications in different states.
-These application states include `running`, `accepted`, `rejected`, `failed` and `completed`.
-`<queue_name> queue_app` metrics record container states including `released`, `allocated`.
-
-Prior to `1.5.0` queue metrics were pushed to a separate subsystem for each queue. In `1.5.0`
-fixed metrics with `<queue name>` labels were introduced. Metrics using `<queue name>` subsystems
-will be **deprecated in `1.6.0` and removed in `1.7.0`** in favor of a `<queue name>` label based approach.
-
-### Label
-(Introduced in `1.5.0`)
-
-**Metric Type**: `gauge`
-
-**Namespace**: `yunikorn`
-
-**Label**: `queue: <queue name>`
-
-**TYPE**: `yunikorn_queue_app`
-
-```json
-yunikorn_queue_app{queue="root.default",state="accepted"} 3
-yunikorn_queue_app{queue="root.default",state="running"} 3
-```
-
-### Subsystem
-|:exclamation: To be deprecated in `1.6.0` and removed in `1.7.0`|
-|----------------------------------------------------------------|
-
-**Metric Type**: `gauge`
-
-**Namespace**: `yunikorn`
-
-**Subsystem**: `<queue name>`
-
-**TYPE**: `yunikorn_<queue name>_queue_app`
-
-```json
-yunikorn_root_default_queue_app{state="accepted"} 3
-yunikorn_root_default_queue_app{state="running"} 3
-```
-
-## Resource
-The `<queue_name> queue_resource` metric to trace the resource in the queue.
-These resource states include `guaranteed`, `max`, `allocated`, `pending`, `preempting`.
-### Label
-(Introduced in `1.5.0`)
-
-**Metric Type**: `gauge`
-
-**Namespace**: `yunikorn`
-
-**Label**: `queue: <queue name>`
-
-**TYPE**: `yunikorn_queue_resource`
-
-```json
-yunikorn_queue_resource{queue="root",resource="ephemeral-storage",state="max"} 9.41009558e+10
-yunikorn_queue_resource{queue="root",resource="hugepages-1Gi",state="max"} 0
-yunikorn_queue_resource{queue="root",resource="hugepages-2Mi",state="max"} 0
-yunikorn_queue_resource{queue="root",resource="memory",state="max"} 1.6223076352e+10
-yunikorn_queue_resource{queue="root",resource="pods",state="max"} 110
-yunikorn_queue_resource{queue="root",resource="vcore",state="max"} 8000
-```
-
-### Subsystem
-|:exclamation: To be deprecated in `1.6.0` and removed in `1.7.0`|
-|----------------------------------------------------------------|
-
-**Metric Type**: `gauge`
-
-**Namespace**: `yunikorn`
-
-**Subsystem**: `<queue name>`
-
-**TYPE**: `yunikorn_<queue name>_queue_resource`
-
-```json
-yunikorn_root_queue_resource{resource="ephemeral-storage",state="max"} 9.41009558e+10
-yunikorn_root_queue_resource{resource="hugepages-1Gi",state="max"} 0
-yunikorn_root_queue_resource{resource="hugepages-2Mi",state="max"} 0
-yunikorn_root_queue_resource{resource="memory",state="max"} 1.6223076352e+10
-yunikorn_root_queue_resource{resource="pods",state="max"} 110
-yunikorn_root_queue_resource{resource="vcore",state="max"} 8000
-```
diff --git a/versioned_docs/version-1.5.0/performance/performance_tutorial.md b/versioned_docs/version-1.5.0/performance/performance_tutorial.md
deleted file mode 100644
index f45bbf2648..0000000000
--- a/versioned_docs/version-1.5.0/performance/performance_tutorial.md
+++ /dev/null
@@ -1,522 +0,0 @@
----
-id: performance_tutorial
-title: Benchmarking Tutorial
-keywords:
- - performance
- - tutorial
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Overview
-
-The YuniKorn community continues to optimize the performance of the scheduler, ensuring that YuniKorn satisfies the performance requirements of large-scale batch workloads. Thus, the community has built some useful tools for performance benchmarking that can be reused across releases. This document introduces all these tools and steps to run them.
-
-## Hardware
-
-Be aware that performance result is highly variable depending on the underlying hardware. All results published in the doc can only be used as references. We encourage each individual to run similar tests on their own environments in order to get a result based on your own hardware. This doc is just for demonstration purpose.
-
-A list of servers being used in this test are (Huge thanks to [National Taichung University of Education](https://www.ntcu.edu.tw), [Kuan-Chou Lai](https://sites.google.com/mail.ntcu.edu.tw/kclai) for providing these servers for running tests):
-
-| Manchine Type | CPU | Memory | Download/upload(Mbps) |
-| --------------------- | --- | ------ | --------------------- |
-| HP | 16 | 36G | 525.74/509.86 |
-| HP | 16 | 30G | 564.84/461.82 |
-| HP | 16 | 30G | 431.06/511.69 |
-| HP | 24 | 32G | 577.31/576.21 |
-| IBM blade H22 | 16 | 38G | 432.11/4.15 |
-| IBM blade H22 | 16 | 36G | 714.84/4.14 |
-| IBM blade H22 | 16 | 42G | 458.38/4.13 |
-| IBM blade H22 | 16 | 42G | 445.42/4.13 |
-| IBM blade H22 | 16 | 32G | 400.59/4.13 |
-| IBM blade H22 | 16 | 12G | 499.87/4.13 |
-| IBM blade H23 | 8 | 32G | 468.51/4.14 |
-| WS660T | 8 | 16G | 87.73/86.30 |
-| ASUSPRO D640MB_M640SA | 4 | 8G | 92.43/93.77 |
-| PRO E500 G6_WS720T | 16 | 8G | 90/87.18 |
-| WS E500 G6_WS720T | 8 | 40G | 92.61/89.78 |
-| E500 G5 | 8 | 8G | 91.34/85.84 |
-| WS E500 G5_WS690T | 12 | 16G | 92.2/93.76 |
-| WS E500 G5_WS690T | 8 | 32G | 91/89.41 |
-| WS E900 G4_SW980T | 80 | 512G | 89.24/87.97 |
-
-The following steps are needed for each server, otherwise the large scale testing may fail due to the limited number of users/processes/open-files.
-
-### 1. Set /etc/sysctl.conf
-```
-kernel.pid_max=400000
-fs.inotify.max_user_instances=50000
-fs.inotify.max_user_watches=52094
-```
-### 2. Set /etc/security/limits.conf
-
-```
-* soft nproc 4000000
-* hard nproc 4000000
-root soft nproc 4000000
-root hard nproc 4000000
-* soft nofile 50000
-* hard nofile 50000
-root soft nofile 50000
-root hard nofile 50000
-```
----
-
-## Deploy workflow
-
-Before going into the details, here are the general steps used in our tests:
-
-- [Step 1](#Kubernetes): Properly configure Kubernetes API server and controller manager, then add worker nodes.
-- [Step 2](#Setup-Kubemark): Deploy hollow pods,which will simulate worker nodes, name hollow nodes. After all hollow nodes in ready status, we need to cordon all native nodes, which are physical presence in the cluster, not the simulated nodes, to avoid we allocated test workload pod to native nodes.
-- [Step 3](#Deploy-YuniKorn): Deploy YuniKorn using the Helm chart on the master node, and scale down the Deployment to 0 replica, and [modify the port](#Setup-Prometheus) in `prometheus.yml` to match the port of the service.
-- [Step 4](#Run-tests): Deploy 50k Nginx pods for testing, and the API server will create them. But since the YuniKorn scheduler Deployment has been scaled down to 0 replica, all Nginx pods will be stuck in pending.
-- [Step 5](../user_guide/troubleshooting.md#restart-the-scheduler): Scale up The YuniKorn Deployment back to 1 replica, and cordon the master node to avoid YuniKorn allocating Nginx pods there. In this step, YuniKorn will start collecting the metrics.
-- [Step 6](#Collect-and-Observe-YuniKorn-metrics): Observe the metrics exposed in Prometheus UI.
----
-
-## Setup Kubemark
-
-[Kubemark](https://github.com/kubernetes/kubernetes/tree/master/test/kubemark) is a performance testing tool which allows users to run experiments on simulated clusters. The primary use case is the scalability testing. The basic idea is to run tens or hundreds of fake kubelet nodes on one physical node in order to simulate large scale clusters. In our tests, we leverage Kubemark to simulate up to a 4K-node cluster on less than 20 physical nodes.
-
-### 1. Build image
-
-##### Clone kubernetes repo, and build kubemark binary file
-
-```
-git clone https://github.com/kubernetes/kubernetes.git
-```
-```
-cd kubernetes
-```
-```
-KUBE_BUILD_PLATFORMS=linux/amd64 make kubemark GOFLAGS=-v GOGCFLAGS="-N -l"
-```
-
-##### Copy kubemark binary file to the image folder and build kubemark docker image
-
-```
-cp _output/bin/kubemark cluster/images/kubemark
-```
-```
-IMAGE_TAG=v1.XX.X make build
-```
-After this step, you can get the kubemark image which can simulate cluster node. You can upload it to Docker-Hub or just deploy it locally.
-
-### 2. Install Kubermark
-
-##### Create kubemark namespace
-
-```
-kubectl create ns kubemark
-```
-
-##### Create configmap
-
-```
-kubectl create configmap node-configmap -n kubemark --from-literal=content.type="test-cluster"
-```
-
-##### Create secret
-
-```
-kubectl create secret generic kubeconfig --type=Opaque --namespace=kubemark --from-file=kubelet.kubeconfig={kubeconfig_file_path} --from-file=kubeproxy.kubeconfig={kubeconfig_file_path}
-```
-### 3. Label node
-
-We need to label all native nodes, otherwise the scheduler might allocate hollow pods to other simulated hollow nodes. We can leverage Node selector in yaml to allocate hollow pods to native nodes.
-
-```
-kubectl label node {node name} tag=tagName
-```
-
-### 4. Deploy Kubemark
-
-The hollow-node.yaml is down below, there are some parameters we can configure.
-
-```
-apiVersion: v1
-kind: ReplicationController
-metadata:
- name: hollow-node
- namespace: kubemark
-spec:
- replicas: 2000 # the node number you want to simulate
- selector:
- name: hollow-node
- template:
- metadata:
- labels:
- name: hollow-node
- spec:
- nodeSelector: # leverage label to allocate to native node
- tag: tagName
- initContainers:
- - name: init-inotify-limit
- image: docker.io/busybox:latest
- imagePullPolicy: IfNotPresent
- command: ['sysctl', '-w', 'fs.inotify.max_user_instances=200'] # set as same as max_user_instance in actual node
- securityContext:
- privileged: true
- volumes:
- - name: kubeconfig-volume
- secret:
- secretName: kubeconfig
- - name: logs-volume
- hostPath:
- path: /var/log
- containers:
- - name: hollow-kubelet
- image: 0yukali0/kubemark:1.20.10 # the kubemark image you build
- imagePullPolicy: IfNotPresent
- ports:
- - containerPort: 4194
- - containerPort: 10250
- - containerPort: 10255
- env:
- - name: NODE_NAME
- valueFrom:
- fieldRef:
- fieldPath: metadata.name
- command:
- - /kubemark
- args:
- - --morph=kubelet
- - --name=$(NODE_NAME)
- - --kubeconfig=/kubeconfig/kubelet.kubeconfig
- - --alsologtostderr
- - --v=2
- volumeMounts:
- - name: kubeconfig-volume
- mountPath: /kubeconfig
- readOnly: true
- - name: logs-volume
- mountPath: /var/log
- resources:
- requests: # the resource of hollow pod, can modify it.
- cpu: 20m
- memory: 50M
- securityContext:
- privileged: true
- - name: hollow-proxy
- image: 0yukali0/kubemark:1.20.10 # the kubemark image you build
- imagePullPolicy: IfNotPresent
- env:
- - name: NODE_NAME
- valueFrom:
- fieldRef:
- fieldPath: metadata.name
- command:
- - /kubemark
- args:
- - --morph=proxy
- - --name=$(NODE_NAME)
- - --use-real-proxier=false
- - --kubeconfig=/kubeconfig/kubeproxy.kubeconfig
- - --alsologtostderr
- - --v=2
- volumeMounts:
- - name: kubeconfig-volume
- mountPath: /kubeconfig
- readOnly: true
- - name: logs-volume
- mountPath: /var/log
- resources: # the resource of hollow pod, can modify it.
- requests:
- cpu: 20m
- memory: 50M
- tolerations:
- - effect: NoExecute
- key: node.kubernetes.io/unreachable
- operator: Exists
- - effect: NoExecute
- key: node.kubernetes.io/not-ready
- operator: Exists
-```
-
-once done editing, apply it to the cluster:
-
-```
-kubectl apply -f hollow-node.yaml
-```
-
----
-
-## Deploy YuniKorn
-
-#### Install YuniKorn with helm
-
-We can install YuniKorn with Helm, please refer to this [doc](https://yunikorn.apache.org/docs/#install).
-We need to tune some parameters based on the default configuration. We recommend to clone the [release repo](https://github.com/apache/yunikorn-release) and modify the parameters in `value.yaml`.
-
-```
-git clone https://github.com/apache/yunikorn-release.git
-cd helm-charts/yunikorn
-```
-
-#### Configuration
-
-The modifications in the `value.yaml` are:
-
-- increased memory/cpu resources for the scheduler pod
-- disabled the admission controller
-- set the app sorting policy to FAIR
-
-please see the changes below:
-
-```
-resources:
- requests:
- cpu: 14
- memory: 16Gi
- limits:
- cpu: 14
- memory: 16Gi
-```
-```
-embedAdmissionController: false
-```
-```
-configuration: |
- partitions:
- -
- name: default
- queues:
- - name: root
- submitacl: '*'
- queues:
- -
- name: sandbox
- properties:
- application.sort.policy: fair
-```
-
-#### Install YuniKorn with local release repo
-
-```
-Helm install yunikorn . --namespace yunikorn
-```
-
----
-
-## Setup Prometheus
-
-YuniKorn exposes its scheduling metrics via Prometheus. Thus, we need to set up a Prometheus server to collect these metrics.
-
-### 1. Download Prometheus release
-
-```
-wget https://github.com/prometheus/prometheus/releases/download/v2.30.3/prometheus-2.30.3.linux-amd64.tar.gz
-```
-```
-tar xvfz prometheus-*.tar.gz
-cd prometheus-*
-```
-
-### 2. Configure prometheus.yml
-
-```
-global:
- scrape_interval: 3s
- evaluation_interval: 15s
-
-scrape_configs:
- - job_name: 'yunikorn'
- scrape_interval: 1s
- metrics_path: '/ws/v1/metrics'
- static_configs:
- - targets: ['docker.for.mac.host.internal:9080']
- # 9080 is internal port, need port forward or modify 9080 to service's port
-```
-
-### 3. Launch Prometheus
-```
-./prometheus --config.file=prometheus.yml
-```
-
----
-## Run tests
-
-Once the environment is setup, you are good to run workloads and collect results. YuniKorn community has some useful tools to run workloads and collect metrics, more details will be published here.
-
-### 1. Scenarios
-In performance tools, there are three types of tests and feedbacks.
-
-| Test type | Description | Diagram | Log |
-| --------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------- | ----------------------------- |
-| node fairness | Monitor node resource usage(allocated/capicity) with lots of pods requests | Exist | Exist |
-| thourghput | Measure schedulers' throughput by calculating how many pods are allocated per second based on the pod start time | Exist | None |
-
-### 2. Build tool
-The performance tool is available in [yunikorn release repo](https://github.com/apache/yunikorn-release.git),clone the repo to your workspace.
-```
-git clone https://github.com/apache/yunikorn-release.git
-```
-Build the tool:
-```
-cd yunikorn-release/perf-tools/
-make build
-cd target/perf-tools-bin
-```
-It will look like this.
-
-
-### 3. Set test configuration
-Before start tests, check configuration whether meet your except.
-Default output path is `/tmp`, you can modify `common.outputrootpath` to change it.
-If you set these fields with large number to cause timeout problem, increase value in `common.maxwaitseconds` to allow it.
-
-#### Throughput case
-
-| Field | Description |
-| --- | --- |
-| SchedulerNames | List of scheduler will run the test |
-| ShowNumOfLastTasks | Show metadata of last number of pods |
-| CleanUpDelayMs | Controll period to refresh deployments status and print log |
-| RequestConfigs | Set resource request and decide number of deployments and pods per deployment with `repeat` and `numPods` |
-
-In this case,yunikorn and default scheduler will sequentially separately create ten deployments which contains fifty pods.
-It will look like these.
-
-
-
-#### Node fairness case
-
-| Field | Description |
-| --- | --- |
-| SchedulerNames | List of schduler will run the test |
-| NumPodsPerNode | It equals that total pods divided by nodes |
-| AllocatePercentage | Allow how much percentage of allocatable resource is allowed to allocate |
-
-Total number of pods will be multiplication of number of ready nodes and `NumPodsPerNode`.
-In following figure, there are thirteen ready nodes and `NumPodsPerNode` is eighty.
-There will be one thousand fourty pods created.
-
-
-
-#### e2e perf case
-Its field is similar to throughput one but there is only scheduler in each case.
-
-
-
-### 4. Diagrams and logs
-```
-./perf-tools
-```
-It will show result log when each case finished.
-When tests finished, it will look like
-
-We can find result diagrams and logs in `common.outputrootpath` which is in conf.yaml.
-Related diagrams and logs will be like this.
-
----
-
-## Collect and Observe YuniKorn metrics
-
-After Prometheus is launched, YuniKorn metrics can be easily collected. Here is the [docs](metrics.md) of YuniKorn metrics. YuniKorn tracks some key scheduling metrics which measure the latency of some critical scheduling paths. These metrics include:
-
- - **scheduling_latency_seconds:** Latency of the main scheduling routine, in seconds.
- - **app_sorting_latency_seconds**: Latency of all applications sorting, in seconds.
- - **node_sorting_latency_seconds**: Latency of all nodes sorting, in seconds.
- - **queue_sorting_latency_seconds**: Latency of all queues sorting, in seconds.
- - **container_allocation_attempt_total**: Total number of attempts to allocate containers. State of the attempt includes `allocated`, `rejected`, `error`, `released`. Increase only.
-
-you can select and generate graph on Prometheus UI easily, such as:
-
-
-
-
----
-
-## Performance Tuning
-
-### Kubernetes
-
-The default K8s setup has limited concurrent requests which limits the overall throughput of the cluster. In this section, we introduced a few parameters that need to be tuned up in order to increase the overall throughput of the cluster.
-
-#### kubeadm
-
-Set pod-network mask
-
-```
-kubeadm init --pod-network-cidr=10.244.0.0/8
-```
-
-#### CNI
-
-Modify CNI mask and resources.
-
-```
- net-conf.json: |
- {
- "Network": "10.244.0.0/8",
- "Backend": {
- "Type": "vxlan"
- }
- }
-```
-```
- resources:
- requests:
- cpu: "100m"
- memory: "200Mi"
- limits:
- cpu: "100m"
- memory: "200Mi"
-```
-
-
-#### Api-Server
-
-In the Kubernetes API server, we need to modify two parameters: `max-mutating-requests-inflight` and `max-requests-inflight`. Those two parameters represent the API request bandwidth. Because we will generate a large amount of pod request, we need to increase those two parameters. Modify `/etc/kubernetes/manifest/kube-apiserver.yaml`:
-
-```
---max-mutating-requests-inflight=3000
---max-requests-inflight=3000
-```
-
-#### Controller-Manager
-
-In the Kubernetes controller manager, we need to increase the value of three parameters: `node-cidr-mask-size`, `kube-api-burst` and `kube-api-qps`. `kube-api-burst` and `kube-api-qps` control the server side request bandwidth. `node-cidr-mask-size` represents the node CIDR. it needs to be increased as well in order to scale up to thousands of nodes.
-
-
-Modify `/etc/kubernetes/manifest/kube-controller-manager.yaml`:
-
-```
---node-cidr-mask-size=21 //log2(max number of pods in cluster)
---kube-api-burst=3000
---kube-api-qps=3000
-```
-
-#### kubelet
-
-In single worker node, we can run 110 pods as default. But to get higher node resource utilization, we need to add some parameters in Kubelet launch command, and restart it.
-
-Modify start arg in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`, add `--max-Pods=300` behind the start arg and restart
-
-```
-systemctl daemon-reload
-systemctl restart kubelet
-```
-
----
-
-## Summary
-
-With Kubemark and Prometheus, we can easily run benchmark testing, collect YuniKorn metrics and analyze the performance. This helps us to identify the performance bottleneck in the scheduler and further eliminate them. The YuniKorn community will continue to improve these tools in the future, and continue to gain more performance improvements.
diff --git a/versioned_docs/version-1.5.0/user_guide/acls.md b/versioned_docs/version-1.5.0/user_guide/acls.md
deleted file mode 100644
index c1fd7f2f0c..0000000000
--- a/versioned_docs/version-1.5.0/user_guide/acls.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-id: acls
-title: ACLs
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-:::info
-User information is passed to the core scheduler from the kubernetes shim using the methodology defined [here](usergroup_resolution)
-:::
-
-## Usage
-Access Control Lists are generic for YuniKorn.
-They can be used in multiple places in YuniKorn.
-The current use case is limited to queue ACLs.
-
-Access control lists give access to the users and groups that have been specified in the list.
-They do not provide the possibility to explicitly remove or deny access to the users and groups specified in the list.
-
-If there is no access control list is configured access is *denied* by default.
-
-## Syntax
-The access control list is defined as:
-```
-ACL ::= “*” | userlist [ “ “ grouplist ]
-userlist ::= “” | user { “,” user }
-grouplist ::= “” | group { “,” group }
-```
-
-This definition specifies a wildcard of * which results in access for everyone.
-
-If the user list is empty and the group list is empty nobody will have access.
-This deny all ACL has two possible representations:
-* an empty access control list. (implicit)
-* a single space. (explicit)
-
-## Example config
-
-### Simple examples
-An ACL that allows access to just the user `sue`
-```yaml
- adminacl: sue
-```
-Nobody else will get access, this is just for `sue`.
-`john` and `bob` will be denied access.
-
-An ACL that allows access to the user `sue` and the members of the group `dev`.
-```yaml
- adminacl: sue dev
-```
-The user `sue` gets access based on her explicit mention in the user part of the ACL.
-Even though she is not a member of the group `dev`. Her group membership is irrelevant.
-
-The user named `john` whom is a member of the group `dev` will be allowed access based on his group membership.
-A third user called `bob` whom is not mentioned explicitly and is not a member of the `dev` group will be denied access.
-
-An ACL that allows access to the members of the groups `dev` and `test`.
-```yaml
- adminacl: " dev,test"
-```
-The ACL must start with a space to indicate that there is no user list.
-If the ACL is not correctly quoted the space is dropped by the yaml parser.
-Since the user list is empty none of the users will get access unless they are a member of either the `dev` or `test` group.
-
-Looking at the same three users as before:
-The user `sue` is not a member of either group and is denied access.
-The user named `john` whom is a member of the group `dev` will be allowed access based on his group membership.
-`bob` is not a member of the `dev` group but is a member of `test` and will be allowed access.
-
-### Escaping and quotation marks
-ACLs are currently implemented in the queue configuration which uses a yaml file.
-This places some limitations on the how to escape the values.
-Incorrectly quoted values will cause a yaml parse error or could lead to the incorrect interpretation of the value.
-
-The following points need to be taken into account:
-1. The wildcard entry must be quoted in the yaml config.
-1. A simple list of users with or without it being followed by a list of groups does not need quoting but may be quoted.
-1. An ACL without a user list and just one or more groups must be quoted to find the starting space:
-
-Correctly quoted ACL example
-```yaml
-partitions:
- - name: default
- queues:
- - name: test
- submitacl: "*"
- adminacl: sue dev,test
- - name: product
- submitacl: " product"
-```
-
-## Access check
-The access check follows the pattern:
-* check if the ACL is the wildcard
-* check if the user is in the user list
-* check if any of the groups the user is a member of is part of the group list
-
-If a check matches the ACL allows access and checking is stopped.
-If none of the checks match the ACL denies access.
-
-## User and Group information
-For User & Group resolution, please follow instructions defined [here](usergroup_resolution)
diff --git a/versioned_docs/version-1.5.0/user_guide/deployment_modes.md b/versioned_docs/version-1.5.0/user_guide/deployment_modes.md
deleted file mode 100644
index 6864a9c3ca..0000000000
--- a/versioned_docs/version-1.5.0/user_guide/deployment_modes.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-id: deployment_modes
-title: Deployment Modes
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## YuniKorn deployment modes
-
-YuniKorn can be deployed in two different modes: standard and plugin. In standard mode, YuniKorn runs as a customized
-Kubernetes scheduler. In plugin mode, YuniKorn is implemented as a set of plugins on top of the default Kubernetes
-scheduling framework.
-
-In both cases, it is recommended to run the admission controller as well, as this will ensure that only a single
-scheduler is active within your Kubernetes cluster. In this mode, the default Kubernetes scheduler (which is always running)
-will be bypassed for all pods except YuniKorn itself.
-
-## Which version should I use?
-
-### Standard mode
-
-Standard mode is currently the default. It is stable, efficient, and very performant. It is well-suited for
-deployments where most if not all pods are leveraging the queueing features of YuniKorn.
-
-### Plugin mode
-
-Plugin mode is a new deployment model where the scheduler is implemented on top of the default Kubernetes scheduling
-logic, allowing for better compatibility with the default Kubernetes scheduler. It is well-suited for mixed
-workloads (traditional Kubernetes as well as queued applications).
-
-Plugin mode is currently very new and has therefore not yet reached the maturity level of standard mode.
-
-To activate plugin mode when deploying with Helm, set the variable `enableSchedulerPlugin` to `true`.
-
diff --git a/versioned_docs/version-1.5.0/user_guide/gang_scheduling.md b/versioned_docs/version-1.5.0/user_guide/gang_scheduling.md
deleted file mode 100644
index 1b8dd24bf2..0000000000
--- a/versioned_docs/version-1.5.0/user_guide/gang_scheduling.md
+++ /dev/null
@@ -1,297 +0,0 @@
----
-id: gang_scheduling
-title: Gang Scheduling
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## What is Gang Scheduling
-
-When Gang Scheduling is enabled, YuniKorn schedules the app only when
-the app’s minimal resource request can be satisfied. Otherwise, apps
-will be waiting in the queue. Apps are queued in hierarchy queues,
-with gang scheduling enabled, each resource queue is assigned with the
-maximum number of applications running concurrently with min resource guaranteed.
-
-
-
-## Enable Gang Scheduling
-
-There is no cluster-wide configuration needed to enable Gang Scheduling.
-The scheduler actively monitors the metadata of each app, if the app has included
-a valid taskGroups definition, it will be considered as gang scheduling desired.
-
-:::info Task Group
-A task group is a “gang” of tasks in an app, these tasks are having the same resource profile
-and the same placement constraints. They are considered as homogeneous requests that can be
-treated as the same kind in the scheduler.
-:::
-
-### Prerequisite
-
-For the queues which runs gang scheduling enabled applications, the queue sorting policy should be set to `FIFO`.
-To configure queue sorting policy, please refer to doc: [app sorting policies](sorting_policies.md#application-sorting).
-
-#### Why the `FIFO` sorting policy
-
-When Gang Scheduling is enabled, the scheduler proactively reserves resources
-for each application. If the queue sorting policy is not FIFO-based (StateAware is FIFO based sorting policy),
-the scheduler might reserve partial resources for each app and causing resource segmentation issues.
-
-#### Side effects of `StateAware` sorting policy
-
-We do not recommend using `StateAware`, even-though it is a FIFO based policy. A failure of the first pod or a long initialisation period of that pod could slow down the processing.
-This is specifically an issue with Spark jobs when the driver performs a lot of pre-processing before requesting the executors.
-The `StateAware` timeout in those cases would slow down processing to just one application per timeout.
-This in effect will overrule the gang reservation and cause slowdowns and excessive resource usage.
-`StateAware` sorting is **deprecated** in YuniKorn 1.5.0 and will be **removed** from YuniKorn 1.6.0.
-
-### App Configuration
-
-On Kubernetes, YuniKorn discovers apps by loading metadata from individual pod, the first pod of the app
-is required to include a full copy of app metadata. If the app does not have any notion about the first or second pod,
-then all pods are required to carry the same taskGroups info. Gang scheduling requires taskGroups definition,
-which can be specified via pod annotations. The required fields are:
-
-| Annotation | Value |
-|------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| yunikorn.apache.org/task-group-name | Task group name, it must be unique within the application |
-| yunikorn.apache.org/task-groups | A list of task groups, each item contains all the info defined for the certain task group |
-| yunikorn.apache.org/schedulingPolicyParameters | Optional. A arbitrary key value pairs to define scheduling policy parameters. Please read [schedulingPolicyParameters section](#scheduling-policy-parameters) |
-
-#### How many task groups needed?
-
-This depends on how many different types of pods this app requests from K8s. A task group is a “gang” of tasks in an app,
-these tasks are having the same resource profile and the same placement constraints. They are considered as homogeneous
-requests that can be treated as the same kind in the scheduler. Use Spark as an example, each job will need to have 2 task groups,
-one for the driver pod and the other one for the executor pods.
-
-#### How to define task groups?
-
-The task group definition is a copy of the app’s real pod definition, values for fields like resources, node-selector, toleration
-and affinity should be the same as the real pods. This is to ensure the scheduler can reserve resources with the
-exact correct pod specification.
-
-#### Scheduling Policy Parameters
-
-Scheduling policy related configurable parameters. Apply the parameters in the following format in pod's annotation:
-
-```yaml
-annotations:
- yunikorn.apache.org/schedulingPolicyParameters: "PARAM1=VALUE1 PARAM2=VALUE2 ..."
-```
-
-Currently, the following parameters are supported:
-
-`placeholderTimeoutInSeconds`
-
-Default value: *15 minutes*.
-This parameter defines the reservation timeout for how long the scheduler should wait until giving up allocating all the placeholders.
-The timeout timer starts to tick when the scheduler *allocates the first placeholder pod*. This ensures if the scheduler
-could not schedule all the placeholder pods, it will eventually give up after a certain amount of time. So that the resources can be
-freed up and used by other apps. If non of the placeholders can be allocated, this timeout won't kick-in. To avoid the placeholder
-pods stuck forever, please refer to [troubleshooting](troubleshooting.md#gang-scheduling) for solutions.
-
-` gangSchedulingStyle`
-
-Valid values: *Soft*, *Hard*
-
-Default value: *Soft*.
-This parameter defines the fallback mechanism if the app encounters gang issues due to placeholder pod allocation.
-See more details in [Gang Scheduling styles](#gang-scheduling-styles) section
-
-More scheduling parameters will added in order to provide more flexibility while scheduling apps.
-
-#### Example
-
-The following example is a yaml file for a job. This job launches 2 pods and each pod sleeps 30 seconds.
-The notable change in the pod spec is *spec.template.metadata.annotations*, where we defined `yunikorn.apache.org/task-group-name`
-and `yunikorn.apache.org/task-groups`.
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
- name: gang-scheduling-job-example
-spec:
- completions: 2
- parallelism: 2
- template:
- metadata:
- labels:
- app: sleep
- applicationId: "gang-scheduling-job-example"
- queue: root.sandbox
- annotations:
- yunikorn.apache.org/task-group-name: task-group-example
- yunikorn.apache.org/task-groups: |-
- [{
- "name": "task-group-example",
- "minMember": 2,
- "minResource": {
- "cpu": "100m",
- "memory": "50M"
- },
- "nodeSelector": {},
- "tolerations": [],
- "affinity": {}
- }]
- spec:
- schedulerName: yunikorn
- restartPolicy: Never
- containers:
- - name: sleep30
- image: "alpine:latest"
- command: ["sleep", "30"]
- resources:
- requests:
- cpu: "100m"
- memory: "50M"
-```
-
-When this job is submitted to Kubernetes, 2 pods will be created using the same template, and they all belong to one taskGroup:
-*“task-group-example”*. YuniKorn will create 2 placeholder pods, each uses the resources specified in the taskGroup definition.
-When all 2 placeholders are allocated, the scheduler will bind the the real 2 sleep pods using the spot reserved by the placeholders.
-
-You can add more than one taskGroups if necessary, each taskGroup is identified by the taskGroup name,
-it is required to map each real pod with a pre-defined taskGroup by setting the taskGroup name. Note,
-the task group name is only required to be unique within an application.
-
-### Enable Gang scheduling for Spark jobs
-
-Each Spark job runs 2 types of pods, driver and executor. Hence, we need to define 2 task groups for each job.
-The annotations for the driver pod looks like:
-
-```yaml
-Annotations:
- yunikorn.apache.org/schedulingPolicyParameters: “placeholderTimeoutSeconds=30”
- yunikorn.apache.org/taskGroupName: “spark-driver”
- yunikorn.apache.org/taskGroup: “
- TaskGroups: [
- {
- Name: “spark-driver”,
- minMember: 1,
- minResource: {
- Cpu: 1,
- Memory: 2Gi
- },
- Node-selector: ...,
- Tolerations: ...,
- Affinity: ...
- },
- {
- Name: “spark-executor”,
- minMember: 10,
- minResource: {
- Cpu: 1,
- Memory: 2Gi
- }
- }
- ]
- ”
-```
-
-:::note
-The TaskGroup resources must account for the memory overhead for Spark drivers and executors.
-See the [Spark documentation](https://spark.apache.org/docs/latest/configuration.html#application-properties) for details on how to calculate the values.
-:::
-
-For all the executor pods,
-
-```yaml
-Annotations:
- # the taskGroup name should match to the names
- # defined in the taskGroups field
- yunikorn.apache.org/taskGroupName: “spark-executor”
-```
-
-Once the job is submitted to the scheduler, the job won’t be scheduled immediately.
-Instead, the scheduler will ensure it gets its minimal resources before actually starting the driver/executors.
-
-## Gang scheduling Styles
-
-There are 2 gang scheduling styles supported, Soft and Hard respectively. It can be configured per app-level to define how the app will behave in case the gang scheduling fails.
-
-- `Hard style`: when this style is used, we will have the initial behavior, more precisely if the application cannot be scheduled according to gang scheduling rules, and it times out, it will be marked as failed, without retrying to schedule it.
-- `Soft style`: when the app cannot be gang scheduled, it will fall back to the normal scheduling, and the non-gang scheduling strategy will be used to achieve the best-effort scheduling. When this happens, the app transits to the Resuming state and all the remaining placeholder pods will be cleaned up.
-
-**Default style used**: `Soft`
-
-**Enable a specific style**: the style can be changed by setting in the application definition the ‘gangSchedulingStyle’ parameter to Soft or Hard.
-
-#### Example
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
- name: gang-app-timeout
-spec:
- completions: 4
- parallelism: 4
- template:
- metadata:
- labels:
- app: sleep
- applicationId: gang-app-timeout
- queue: fifo
- annotations:
- yunikorn.apache.org/task-group-name: sched-style
- yunikorn.apache.org/schedulingPolicyParameters: "placeholderTimeoutInSeconds=60 gangSchedulingStyle=Hard"
- yunikorn.apache.org/task-groups: |-
- [{
- "name": "sched-style",
- "minMember": 4,
- "minResource": {
- "cpu": "1",
- "memory": "1000M"
- },
- "nodeSelector": {},
- "tolerations": [],
- "affinity": {}
- }]
- spec:
- schedulerName: yunikorn
- restartPolicy: Never
- containers:
- - name: sleep30
- image: "alpine:latest"
- imagePullPolicy: "IfNotPresent"
- command: ["sleep", "30"]
- resources:
- requests:
- cpu: "1"
- memory: "1000M"
-
-```
-
-## Verify Configuration
-
-To verify if the configuration has been done completely and correctly, check the following things:
-1. When an app is submitted, verify the expected number of placeholders are created by the scheduler.
-If you define 2 task groups, 1 with minMember 1 and the other with minMember 5, that means we are expecting 6 placeholder
-gets created once the job is submitted.
-2. Verify the placeholder spec is correct. Each placeholder needs to have the same info as the real pod in the same taskGroup.
-Check field including: namespace, pod resources, node-selector, toleration and affinity.
-3. Verify the placeholders can be allocated on correct type of nodes, and verify the real pods are started by replacing the placeholder pods.
-
-## Troubleshooting
-
-Please see the troubleshooting doc when gang scheduling is enabled [here](troubleshooting.md#gang-scheduling).
diff --git a/versioned_docs/version-1.5.0/user_guide/labels_and_annotations_in_yunikorn.md b/versioned_docs/version-1.5.0/user_guide/labels_and_annotations_in_yunikorn.md
deleted file mode 100644
index 550feaef03..0000000000
--- a/versioned_docs/version-1.5.0/user_guide/labels_and_annotations_in_yunikorn.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-id: labels_and_annotations_in_yunikorn
-title: Labels and Annotations in YuniKorn
----
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Labels and Annotations in YuniKorn
-YuniKorn utilizes several Kubernetes labels and annotations to support various features:
-
-### Labels in YuniKorn
-| Name | Description |
-|-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `applicationId` | Associates this pod with an application. |
-| `queue` | Selects the YuniKorn queue this application should be scheduled in. This may be ignored if a placement policy is in effect. |
-| `spark-app-selector` | Alternative method of specifying `applicationId` used by Spark Operator if the label `applicationId` and annotation `yunikorn.apache.org/app-id` unset. |
-| [DEPRECATED] `disableStateAware` | If present, disables the YuniKorn state-aware scheduling policy for this pod. Set internally by the YuniKorn admission controller. |
-| `placeholder` | Set if this pod represents a placeholder for gang scheduling. Set internally by YuniKorn. |
-
-### Annotations in YuniKorn
-All annotations are under the namespace `yunikorn.apache.org`. For example `yunikorn.apache.org/app-id`.
-
-| Name | Description |
-|-------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `app-id` | Assoiates this pod with an application.<br/>The priority of applicationID is determined by: annotation `yunikorn.apache.org/app-id` > label `applicationId` > label `spark-app-selector`. |
-| `queue` | Selects the YuniKorn queue this application should be scheduled in.<br/>The priority of queue is determined by: label `queue` > annotation `yunikorn.apache.org/queue` > default. |
-| `task-group-name` | Sets the task group name this pod belongs to for the purposes of gang scheduling. It must be listed within `task-groups`. |
-| `task-groups` | Defines the set of task groups for this application for gang scheduling. Each pod within an application must define all task groups. |
-| `schedulingPolicyParameters` | Arbitrary key-value pairs used to customize scheduling policies such as gang scheduling. |
-| `placeholder` | Set if this pod represents a placeholder for gang scheduling. Set internally by YuniKorn. |
-| `allow-preemption` | The `allow-preemption` annotation can be set on the Pod or PriorityClass object. The annotation in Pod takes priority over PriorityClass. It will trigger opt out of preemption for pods. Further details can be found in the [DaemonSet Scheduling using Simple Preemptor](./../design/simple_preemptor) documentation. |
-| `parentqueue` | Define a parent queue for a set of K8s namespaces. Further details can be found in the [ Resource Quota Management](resource_quota_management#parent-queue-mapping-for-namespaces) documentation. |
-| `namespace.quota` | Set the maximum capacity of the queue mapped to this namespace. Further details can be found in the [ Resource Quota Management](resource_quota_management#namespace-quota) documentation. |
-| [DEPRECATED] `namespace.max.cpu` | Replaced with ``namespace.quota`` since version 1.2.0 |
-| [DEPRECATED] `namespace.max.memory` | Replaced with `namespace.quota` since version 1.2.0 |
-| `namespace.enableYuniKorn` | Controls which namespaces will have pods forwarded to Yunikorn for scheduling. Further details can be found in the [Service Configuration #admission-controller-filtering-settings](service_config#admission-controller-filtering-settings)documentation. |
-| `namespace.generateAppId` | Controls which namespaces will have pods labeled with an `applicationId`. Further details can be found in the [Service Configuration #admission-controller-filtering-settings](service_config#admission-controller-filtering-settings) documentation. |
-
-For more details surrounding gang-scheduling labels and annotations, please refer to the documentation on [gang scheduling](user_guide/gang_scheduling.md).
diff --git a/versioned_docs/version-1.5.0/user_guide/placement_rules.md b/versioned_docs/version-1.5.0/user_guide/placement_rules.md
deleted file mode 100644
index 3b8b14358d..0000000000
--- a/versioned_docs/version-1.5.0/user_guide/placement_rules.md
+++ /dev/null
@@ -1,355 +0,0 @@
----
-id: placement_rules
-title: App Placement Rules
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-The basics for the placement rules are described in the [scheduler configuration design document](design/scheduler_configuration.md#placement-rules-definition).
-Multiple rules can be chained to form a placement policy.
-[Access control lists](user_guide/acls.md) and rule filters are defined per rule and enforced per rule.
-This document explains how to build a policy, including the rule usage, that is part of the scheduler with examples.
-
-## Configuration
-Rules are defined per partition as part of the scheduler queue configuration.
-The order that the rules are defined in is the order in which they are executed.
-If a rule matches the policy will stop executing the remaining rules.
-
-A matching rule generates a fully qualified queue name.
-This means that the name returned starts at the _root_ queue.
-There is no limit on the number of levels in the queue hierarchy that can be generated.
-
-When a rule is executed the result of rules that have been executed is unknown and not taken into account.
-Similar for rule that have not been executed yet: rules cannot influence other rules except when they are configured as the [parent](#parent-parameter) rule.
-
-If the policy does not generate a queue name and no more rules are left the application will be rejected.
-
-Basic structure for the rule placement definition in the configuration:
-```yaml
-placementrules:
- - name: <name of the 1st rule>
- - name: <name of the 2nd rule>
-```
-Each rule can take a predefined set of parameters in the configuration.
-The name of the rules that can be used are given in the [rule](#rules) description.
-A rule name is not case sensitive in the configuration.
-Rule name must follow the following naming convention:
-* start with a letter: a-z or A-Z
-* followed by 0 or more characters a-z, A-Z, 0-9 or _
-
-A rule that is not known, i.e. the name does not map to the rules defined below, will cause a initialisation error of the placement manager.
-Rules can also throw a parse error or an error during the initialisation if the parameters are incorrect.
-A rule set with an error can never become active.
-
-A placement manager is considered initialised if it has an active rule set.
-When the configuration is reloaded a new rule set will be created to replace the active rule set.
-In the case that a new rule set loaded contains an error, i.e. is broken, the placement manager ignores the new rule set.
-This means that the placement manager stays in a the state it was in when a broken rule set is loaded.
-If the placement manager keeps using the existing active rule set in the case that it was already initialised.
-A message will be logged about the broken and ignored configuration.
-
-Dots "." in the rule result are replaced by the string "\_dot_".
-A dot is replaced because it is used as the hierarchy separator in the fully qualified queue name.
-Replacing the dot occurs before the full queue hierarchy is build and the result is qualified.
-This means that we allow user name and or tag values to contain dots without the dots affecting the queue hierarchy.
-For queues in the configuration that as an example must map to username with a dot you must specify them as follows:
-A user rule with the user `user.name` will generate the queue name `root.user_dot_name` as output.
-If that "user queue" must be added to the configuration the `user_dot_name` name should be used.
-
-### Create parameter
-The create parameter is a boolean flag that defines if a queue that is generated by the rule may be created if it does not exist.
-There is no guarantee that the queue will be created because the existing queues might prevent the queue creation.
-If the queue generated by the rule does not exist and the flag is not set to _true_ the result of the rule will be a fail.
-
-Basic yaml entry for a rule with `create` flag:
-```yaml
-placementrules:
- - name: <name of the rule>
- create: true
-```
-
-The default value is _false_.
-Allowed values: _true_ or _false_, any other value will cause a parse error.
-
-### Parent parameter
-The parent parameter allows specifying a rule that generates a parent queue for the current rule.
-Parent rules can be nested, a parent rule _may_ contain another parent rule.
-There is no enforced limit of parent rules that can be nested.
-
-A parent rule is treated as if it was a rule specified at the top level of the list and thus has the same parameters and requirements as a any other rule in the placement definition.
-The exception is that using a parent rule on a rule that already generates a fully qualified queue is considered a configuration error.
-This error can only occur on the rule of type [fixed](#fixed-rule), see the rule specification for more details.
-
-NOTE: the rule execution traverses down the list of parent rules and executes the last one in the list first.
-This means that the last parent rule will generate the queue directly below the root.
-See the examples for details.
-
-Basic yaml entry for a rule with a `parent` rule:
-```yaml
-placementrules:
- - name: <name of the rule>
- parent:
- name: <name of the parent rule>
-```
-
-The default value is _no_ parent.
-
-### Filter parameter
-The filter on a rule allows filtering the users that the rule applies to.
-A filter is a complex configuration object.
-
-The _users_ and _groups_ that can be configured can be one of two types:
-* a regular expression
-* a list of users or groups.
-
-If the entry for users or groups contains more than 1 entry in the yaml it is always considered a list of either users or groups.
-Duplicate entries in the lists are ignored and do not cause an error.
-Specifying a regular expression beside other list elements is not allowed.
-
-User and group names follow the standard linux user and group conventions.
-For user names:
-* start with a letter: a-z or A-Z
-* followed by 0 or more characters a-z, A-Z, 0-9 or _ . @ -
-* the last character may also be a $
-
-For group names:
-* start with a letter: a-z or A-Z
-* followed by 0 or more characters a-z, A-Z, 0-9 or _ -
-
-If the list is exactly one entry it can be either a single user or group or a regular expression.
-When an entry contains a character that is not allowed in a user or group name the entry is considered a regular expression.
-The regular expression must compile as specified.
-A regular expression that does not compile is ignored.
-
-Specifically for the group regular expression: matching is performed one group at a time not the against the list of groups.
-
-Basic `filter` yaml entry:
-```yaml
-filter:
- type: deny
- users:
- - <user name or regexp>
- - <user name>
- groups:
- - <group name or regexp>
- - <group name>
-```
-
-The default value is _no_ filter.
-
-### Value parameter
-This is a generic value that can be used to pass to a rule to implement or alter its behaviour.
-The value It is used by the [fixed](#fixed-rule) and the [tag](#tag-rule) rule.
-The value is a single value in string form and is not interpreted or manipulated by the system.
-
-Basic yaml entry for a rule with a `value` set:
-```yaml
-placementrules:
- - name: <name of the rule>
- value: "any string"
-```
-
-The default is _no_ value.
-
-## Access Control List
-Access control lists are not defined in the rules but they impact the outcome of the placement policy.
-Two access control lists can be defined on a queue:
-1. Submit ACL: _submitacl_
-1. Administration ACL: _adminacl_
-
-The placement rule will only match if the ACL of the queue allows submit access via either ACL.
-The administrative queue ACL also provides _submit_ access.
-If the queue does not exist or does not have an ACL set, the ACL of the parent queue is checked.
-This recursive check is repeated until an ACL provides access or after the ACL of the root queue is checked.
-
-For more detail on the ACL syntax check the [ACL documentation](user_guide/acls.md).
-
-## Rules
-### Provided Rule
-Name to be used in the configuration: *provided*
-
-Returns the queue provided during the submission of the application.
-The behaviour of the this rule is to fully qualify the queue provided by the application if the queue is not fully qualified.
-If a parent rule is set and the queue provided in the application submission is fully qualified then the parent rule will not be executed.
-
-Supported parameters:
-* create
-* parent
-* filter
-
-Example: create the queue passed in by the user if it does not exist under the users name
-```yaml
-placementrules:
- - name: provided
- create: true
- parent:
- name: user
- create: true
-```
-Application submit request by the user `developer`, queue in the application on submit: `my_special_queue`<br/>
-Result: `root.developer.my_special_queue` (parent rule set the user name)
-
-Application submit request by the user `developer`, queue in the application on submit: `root.dev_queue`<br/>
-Result: `root.dev_queue` (parent rule ignored)
-
-### User Name Rule
-Name to be used in the configuration: *user*
-
-Returns the queue based on the user name that is part of the submitted application.
-
-Supported parameters:
-* create
-* parent
-* filter
-
-Example: submit to a queue based on the user name, do not create the queue if the queue does not exist:
-```yaml
-placementrules:
- - name: user
- create: false
-```
-
-Application submit request by the user `finance.test`, queue does exist:<br/>
-Result: `root.finance_dot_test` (note the replacement of the dot)
-
-Application submit request by the user `developer`, queue does not exist:<br/>
-Result: failed, next rule executed
-
-### Fixed Rule
-Name to be used in the configuration: *fixed*
-
-Returns the name configured in the rule parameter _value_.
-The value configured must be a legal queue name or queue hierarchy.
-The name does not have to be a fully qualified queue name.
-The hierarchy in the name uses a dot as a separator for the queue names at the different levels in the hierarchy.
-The fixed rule can only fail if the queue configured does not exist and the create flag is not set as it will always return the configured queue.
-
-If the configured value is a fully qualified queue name configuring a parent rule will be considered an _error_.
-
-Supported parameters:
-* value (required)
-* create
-* parent
-* filter
-
-Example: a fixed queue returned always, without the `create` flag set and thus requires the queue to be defined as a leaf queue in the configuration.
-```yaml
-placementrules:
- - name: fixed
- value: last_resort
-```
-
-Application submit request by the user `developer`, queue in the application on submit: `my_special_queue`<br/>
-Result: `root.last_resort`
-
-### Tag Rule
-Name to be used in the configuration: *tag*
-
-Retrieves the queue name from the applications tags.
-The tag name that is checked for its value is configured in the rule using the `value`.
-Configuring a tag rule without a `value` set is an error, however an application does not have to have the tag set.
-
-If the tag is not set on the application the rule fails.
-If the tag value returned from the application is a fully qualified queue name the parent rule, if configured, will not be executed.
-
-Supported parameters:
-* value (required)
-* create
-* parent
-* filter
-
-Example: place an application based on the kubernetes `namespace` which gets sets automatically in the application when submitted:
-```yaml
-placementrules:
- - name: tag
- value: namespace
- create: true
-```
-
-Application submit request for a kubernetes based application in the namespace `default` by the user `developer`, queue in the application on submit: `my_special_queue`<br/>
-Result: `root.default`
-
-Application submit request for a kubernetes based application in the namespace `testing` by the user `developer`<br/>
-Result: `root.testing`
-
-Application submit request for a non kubernetes based application by the user `developer`<br/>
-Result: failed, next rule executed
-
-## Complex examples
-In this complex example we chain three rules:
-1. a `user` rule, with a parent rule `tag` using the kubernetes namespace, to be used only for users that are part of and "dev" group.
-1. a `tag` rule using the kubernetes namespace, with a parent rule `fixed` using the existing queue `root.namespaces`.
-1. a `fixed` rule to place everything that reaches this point in the `root.default` queue.
-
-Example:
-```yaml
-placementrules:
- - name: user
- create: true
- filter:
- type: allow
- groups:
- - dev*
- parent:
- name: tag
- value: namespace
- - name: tag
- value: namespace
- create: true
- parent:
- name: fixed
- value: root.namespaces
- filter:
- type: allow
- users:
- - john
- - name: fixed
- value: root.default
-```
-
-Application submit request for a kubernetes based application in the namespace `testing` by the user `john`<br/>
-Result: `root.namespaces.testing` (matched in rule 2)
-
-Application submit request for a kubernetes based application in the namespace `newapp` by the user `sarah` with groups membership `sarah, test_app, dev_app`<br/>
-Result: `root.newapp.sarah` (matched in rule 1)
-
-Application submit request for a kubernetes based application in the namespace `testapp` by the user `bob` with groups membership `bob`<br/>
-Result: `root.deault` (matched in rule 3)
-
-In this second example we chain two rules:
-1. a `fixed` rule to place everything in the `root.production` queue
-1. a `user` rule, with the create flag set
-
-In this case however we have ACLs set up on the `root.production` queue to only allow two specific user to use this queue.
-So even if the rule matches unless the user is either `john` or `bob` the application will not be placed in the `production` queue.
-All other users will match the second rule and use their own queue, which is created if it does not exist.
-
-```yaml
-partitions:
- - name: default
- queues:
- - name: production
- submitacl: john,bob
- placementrules:
- - name: fixed
- value: root.production
- - name: user
- create: true
-```
diff --git a/versioned_docs/version-1.5.0/user_guide/preemption.md b/versioned_docs/version-1.5.0/user_guide/preemption.md
deleted file mode 100644
index 019646fc66..0000000000
--- a/versioned_docs/version-1.5.0/user_guide/preemption.md
+++ /dev/null
@@ -1,231 +0,0 @@
----
-id: preemption_cases
-title: Preemption
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-Preemption is an essential feature found in most schedulers, and it plays a crucial role in enabling key system functionalities like DaemonSets in K8s, as well as SLA and prioritization-based features.
-
-This document provides a brief introduction to the concepts and configuration methods of preemption in YuniKorn. For a more comprehensive understanding of YuniKorn's design and practical ideas related to preemption, please refer to the [design document](design/preemption.md).
-
-## Kubernetes Preemption
-
-Preemption in Kubernetes operates based on priorities. Starting from Kubernetes 1.14, you can configure preemption by adding a `preemptionPolicy` to the `PriorityClass`. However, it is important to note that preemption in Kubernetes is solely based on the priority of the pod during scheduling. The full documentation can be found [here](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption).
-
-While Kubernetes does support preemption, it does have some limitations. Preemption in Kubernetes only occurs during the scheduling cycle and does not change once the scheduling is complete. However, when considering batch or data processing workloads, it becomes necessary to account for the possibility of opting out at runtime.
-
-## YuniKorn Preemption
-
-In Yunikorn, we offer two preemption types: general and DaemonSet. DaemonSet preemption is much more straightforward, as it ensures that pods which must run on a particular node are allowed to do so. The rest of the documentation only concerns generic preemption. For a comprehensive explanation of DaemonSet preemption, please consult the [design document](design/simple_preemptor.md).
-
-YuniKorn's generic preemption is based on a hierarchical queue model, enabling pods to opt out of running. Preemption is triggered after a specified delay, ensuring that each queue's resource usage reaches at least the guaranteed amount of resources. To configure the delay time for preemption triggering, you can utilize the `preemption.delay` property in the configuration.
-
-To prevent the occurrence of preemption storms or loops, where subsequent preemption tasks trigger additional preemption tasks, we have designed seven preemption laws. These laws are as follows:
-
-1. Preemption policies are strong suggestions, not guarantees
-2. Preemption can never leave a queue lower than its guaranteed capacity
-3. A task cannot preempt other tasks in the same application
-4. A task cannot trigger preemption unless its queue is under its guaranteed capacity
-5. A task cannot be preempted unless its queue is over its guaranteed capacity
-6. A task can only preempt a task with lower or equal priority
-7. A task cannot preempt tasks outside its preemption fence
-
-For a detailed explanation of these preemption laws, please refer to the preemption [design document](design/preemption.md#the-laws-of-preemption).
-
-Next, we will provide a few examples to help you understand the functionality and impact of preemption, allowing you to deploy it effectively in your environment. You can find the necessary files for the examples in the yunikorn-k8shim/deployment/example/preemption directory.
-
-Included in the files is a YuniKorn configuration that defines the queue configuration as follows:
-
-```bash
-queues.yaml: |
- partitions:
- - name: default
- placementrules:
- - name: provided
- create: true
- queues:
- - name: root
- submitacl: '*'
- properties:
- preemption.policy: fence
- preemption.delay: 10s
- queues:
- - name: 1-normal ...
- - name: 2-no-guaranteed ...
- - name: 3-priority-class ...
- - name: 4-priority-queue ...
- - name: 5-fence ...
-```
-
-Each queue corresponds to a different example, and the preemption will be triggered 10 seconds after deployment, as indicated in the configuration `preemption.delay: 10s`.
-
-### General Preemption Case
-
-In this case, we will demonstrate the outcome of triggering preemption when the queue resources are distributed unevenly in a general scenario.
-
-We will deploy 10 pods with a resource requirement of 1 to both `queue-1` and `queue-2`. First, we deploy to `queue-1` and then introduce a few seconds delay before deploying to `queue-2`. This ensures that the resource usage in `queue-1` will exceed that of `queue-2`, depleting all resources in the parent queue and triggering preemption.
-
-| Queue | Max Resource | Guaranteed Resource |
-| ---------------- | ------------ | ------------------- |
-| `normal` | 12 | - (not configured) |
-| `normal.queue-1` | 10 | 5 |
-| `normal.queue-2` | 10 | 5 |
-
-Result:
-
-When a set of guaranteed resources is defined, preemption aims to ensure that all queues satisfy their guaranteed resources. Preemption stops once the guaranteed resources are met (law 4). A queue may be preempted if it has more resources than its guaranteed amount. For instance, in this case, if queue-1 has fewer resources than its guaranteed amount (\<5), it will not be preempted (law 5).
-
-| Queue | Resource before preemption | Resource after preemption |
-| ---------------- | -------------------------- | ------------------------- |
-| `normal.queue-1` | 10 (victim) | 7 |
-| `normal.queue-2` | 2 | 5 (guaranteed minimum) |
-
-
-
-### Priority
-
-In general, a pod can preempt a pod with equal or lower priority. You can set the priority by defining a [PriorityClass](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) or by utilizing [queue priorities](priorities).
-
-While preemption allows service-type pods to scale up or down through preemption, it can also lead to the preemption of pods that should not be preempted in certain scenarios:
-
-1. Spark Jobs, where the driver pod manages a large number of jobs, and if preempted, all jobs will be affected.
-2. Interactive pods, such as Python notebooks, have a significant impact when restarted and should be avoided from preemption.
-
-To address this issue, we have designed a "do not preempt me" flag. You can set the annotation `yunikorn.apache.org/allow-preemption` to `false` in the PriorityClass to prevent pod requests from being preempted.
-> **_NOTE:_** The flag `yunikorn.apache.org/allow-preemption` is a request only. It is not guaranteed but Pods annotated with this flag will be preempted last.
-
-
-### PriorityClass
-
-In this example, we will demonstrate the configuration of `yunikorn.apache.org/allow-preemption` using PriorityClass and observe its effect. The default value for this configuration is set to `true`.
-
-```bash
-apiVersion: scheduling.k8s.io/v1
-kind: PriorityClass
-metadata:
- name: preemption-not-allow
- annotations:
- "yunikorn.apache.org/allow-preemption": "false"
-value: 0
-```
-
-We will deploy 8 pods with a resource requirement of 1 to `queue-1`, `queue-2`, and `queue-3`, respectively. We will deploy to `queue-1` and `queue-2` first, followed by a few seconds delay before deploying to `queue-3`. This ensures that the resource usage in `queue-1` and `queue-2` will be greater than that in `queue-3`, depleting all resources in the parent queue and triggering preemption.
-
-| Queue | Max Resource | Guaranteed Resource | `allow-preemption` |
-| ------------ | ------------ | ------------------- | ------------------ |
-| `rt` | 16 | - | |
-| `rt.queue-1` | 8 | 3 | `true` |
-| `rt.queue-2` | 8 | 3 | `false` |
-| `rt.queue-3` | 8 | 3 | `true` |
-
-Result:
-
-When preemption is triggered, `queue-3` will start searching for a victim. However, since `queue-2` is set with allow-preemption as false, the resources of `queue-1` will be preempted.
-
-Please note that setting `yunikorn.apache.org/allow-preemption` is a strong recommendation but does not guarantee the lack of preemption. When this flag is set to `false`, it moves the Pod to the back of the preemption list, giving it a lower priority for preemption compared to other Pods. However, in certain scenarios, such as when no other preemption options are available, Pods with this flag may still be preempted.
-
-For example, even with `allow-preemption` set to `false`, DaemonSet pods can still trigger preemption. Additionally, if an application in `queue-1` has a higher priority than one in `queue-3`, the application in `queue-2` will be preempted because an application can never preempt another application with a higher priority. In such cases where no other preemption options exist, the `allow-preemption` flag may not prevent preemption.
-
-
-| Queue | Resource before preemption | Resource after preemption |
-| ------------ | -------------------------- | ------------------------- |
-| `rt.queue-1` | 8 (victim) | 5 |
-| `rt.queue-2` | 8 | 8 |
-| `rt.queue-3` | 0 | 3 (guaranteed minimum) |
-
-
-
-### Priority Queue
-
-In addition to utilizing the default PriorityClass in Kubernetes, you can configure priorities directly on a [YuniKorn queue](priorities).
-
-In the following example, we will demonstrate preemption based on queue priority.
-
-We will deploy five pods with a resource demand of 3 in the `high-pri` queue, `norm-pri` queue, and `low-pri` queue, respectively. We will deploy them to the `norm-pri` queue first, ensuring that the resources in the `root`(parent queue) will be fully utilized. This will result in uneven resource distribution among the queues, triggering preemption.
-
-| Queue | Max Resource | Guaranteed Resource | priority.offset |
-| --------------- | ------------ | ------------------- | --------------- |
-| `root` | 18 | - | |
-| `root.high-pri` | 10 | 6 | 100 |
-| `root.norm-pri` | 18 | 6 | 0 |
-| `root.low-pri` | 10 | 6 | -100 |
-
-Result:
-
-A queue with higher priority can preempt resources from a queue with lower priority, and preemption stops when the queue has preempted enough resources to satisfy its guaranteed resources.
-
-| Queue | Resource before preemption | Resource after preemption |
-| --------------- | -------------------------- | ------------------------- |
-| `root.high-pri` | 0 | 6 (guaranteed minimum) |
-| `root.norm-pri` | 18 (victim) | 12 |
-| `root.low-pri` | 0 | 0 |
-
-
-
-### Preemption Fence
-
-In a multi-tenant environment, it is essential to prevent one tenant from occupying the resources of another tenant. In YuniKorn, we map tenants to a queue hierarchy, the queue hierarchy can thus cross tenant boundaries.
-
-To address this issue, YuniKorn introduces a [preemption fence](design/preemption.md#preemption-fence), which is a setting on the queue that prevents preemption from looking at queues outside the fence boundary. The fence is a one-way fence. It prevents going out (i.e. higher up the queue hierarchy), but does not prevent coming in (or down) the queue hierarchy.
-
-```bash
-...
-queues:
-- name: default
- properties:
- preemption.policy: fence
-```
-
-We will use the following diagram as an example:
-
-
-
-In this example, we will sequentially deploy 15 pods with a resource requirement of 1 to each sub-queue.
-
-First, we deploy `queue-1` in `tenant-a` and wait until the application in `queue-1` occupies all the resources of `tenant-a`. Then, we deploy `queue-2` after the resources of `tenant-a` are fully utilized. Next, we deploy the application `ten-b.queue-3` and allocate resources to the system when the fence queue is full.
-
-| Queue | Max Resource | Guaranteed Resource | fence |
-| ------------------ | ------------ | ------------------- | ----- |
-| `rt` | 3 | - | true |
-| `rt.ten-a` | 15 | 5 | true |
-| `rt.ten-a.queue-1` | 15 | 2 | |
-| `rt.ten-a.queue-2` | 15 | 2 | true |
-| `rt.ten-b` | 15 | 10 | true |
-| `rt.ten-b.queue-3` | 15 | 10 | |
-| `rt.sys` | 15 | 10 | |
-
-Result:
-
-In this example, two imbalances are observed:
-
-- Within `ten-a`, `queue-1` occupies all the resources, while `queue-2` has no resources. However, since `queue-2` is configured with a fence, it cannot acquire resources from outside the fence.
- 
-- Inside the `rt` queue, both `ten-a` and `ten-b` occupy all the resources, while the `sys` queue has no resources, and no fence is set up. Therefore, the `sys` queue can acquire resources from the queues in the hierarchy until its guaranteed resources are met. In this case, the `sys` queue acquires resources from both `ten-a` and `ten-b`.
- 
-
-| Queue | Resource before preemption | Resource after preemption |
-| ------------------ | -------------------------- | ------------------------- |
-| `rt.ten-a` | 15 | 10 |
-| `rt.ten-a.queue-1` | 15 | 10 |
-| `rt.ten-a.queue-2` | 0 | 0 |
-| `rt.ten-b` | 15 | 10 |
-| `rt.ten-b.queue-3` | 15 | 10 |
-| `rt.sys` | 0 | 10 |
\ No newline at end of file
diff --git a/versioned_docs/version-1.5.0/user_guide/prometheus.md b/versioned_docs/version-1.5.0/user_guide/prometheus.md
deleted file mode 100644
index e75bdee503..0000000000
--- a/versioned_docs/version-1.5.0/user_guide/prometheus.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-id: prometheus
-title: Prometheus and Grafana
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-YuniKorn exposes its scheduling metrics via Prometheus. Thus, we need to set up a Prometheus server to collect these metrics.
-
-We will provide two methods for building Prometheus: either running it locally or using Helm to deploy it in your cluster. Additionally, in the Helm version, we will explain how to integrate it with Grafana and provide generic Grafana Dashboards for monitoring Yunikorn's metrics and observing the changes over time.
-
-If you don't know what metric can be used, you can use [REST API](../api/scheduler.md#metrics).
-
-## Run Prometheus locally
-
-### 1. Download Prometheus release
-
-```bash
-wget https://github.com/prometheus/prometheus/releases/download/v2.30.3/prometheus-2.30.3.linux-amd64.tar.gz
-```
-
-```bash
-tar xvfz prometheus-*.tar.gz
-cd prometheus-*
-```
-
-### 2. Configure prometheus.yml
-
-Prometheus collects metrics from *targets* by scraping metrics HTTP endpoints.
-
-```yaml
-global:
- scrape_interval: 3s
- evaluation_interval: 15s
-
-scrape_configs:
- - job_name: 'yunikorn'
- scrape_interval: 1s
- metrics_path: '/ws/v1/metrics'
- static_configs:
- - targets: ['localhost:9080']
- # 9080 is internal port, need port forward or modify 9080 to service's port
-```
-
-### 3. Start port-forward
-
-Port forwarding for the core's web service on the standard port can be turned on via:
-
-```bash
-kubectl port-forward svc/yunikorn-service 9080:9080 -n yunikorn
-```
-
-`9080`is the default port for core's web service.
-
-### 4. Execute prometheus
-
-```bash
-./prometheus --config.file=prometheus.yml
-```
-
-
-
-### 5. Access the Prometheus UI
-
-You should be able to browse to a status page at [localhost:9090](http://localhost:9090/). Give it a couple of seconds to collect data about itself from its own HTTP metrics endpoint.
-
-
-
-You can also verify that Prometheus is serving metrics by navigating to its metrics endpoint:[localhost:9090/metrics](http://localhost:9090/metrics)
-
-## Deploy Prometheus and Grafana in a cluster.
-
-### 1. Add Prometheus repository to helm
-
-```yaml
-# add helm repo
-helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
-helm repo update
-```
-
-### 2. Configuring yunikorn for prometheus
-
-Get the config from repository.
-```yaml
-helm show values prometheus-community/kube-prometheus-stack > /tmp/values.yaml
-```
-
-Add a new job in Prometheus to collect metrics by scraping the metrics HTTP endpoints of the targets.
-
-```yaml
-vim /tmp/values.yaml
-```
-```yaml
-...
-additionalScrapeConfigs:
- - job_name: "yunikorn"
- scrape_interval: 1s
- metrics_path: '/ws/v1/metrics'
- static_configs:
- - targets: ["yunikorn-service.yunikorn.svc.cluster.local:9080"]
-...
... 67746 lines suppressed ...
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org