Add procedure to run several workspaces at a time

Signed-off-by: Anatolii Bazko <abazko@redhat.com>

modules/administration-guide/examples/che-pvc-strategies.adoc

@@ -6,11 +6,11 @@
 One PVC for all workspaces in one {platforms-namespace}
 
 
-| Easy to manage and control storage | If PV does not support `ReadWriteMany` (RWX) access mode, the configuration will work only if one or both of the following apply: 
- 
+| Easy to manage and control storage | If PV does not support `ReadWriteMany` (RWX) access mode, the configuration will work only if one or both of the following apply:
+
 * Each workspace is in a separate {platforms-namespace}
 
-* Only one  workspace is running per {platforms-namespace} at the same time. See xref:installation-guide:configuring-namespace-strategies.adoc[].
+* Only one workspace is running per {platforms-namespace} at the same time. See xref:installation-guide:run-several-workspaces-at-a-time.adoc[].
 |*per-workspace* |
 
 One PVC for one workspace

modules/administration-guide/partials/con_persistent-volume-configuration.adoc

@@ -14,7 +14,7 @@ include::example${project-context}-pvc-strategies.adoc[]
 [id="the-common-pvc-strategy_{context}"]
 == The `common` PVC strategy
 
-All workspaces inside a {platforms-namespace} use the same Persistent Volume Claim (PVC) as the default data storage when storing data such as the following in their declared volumes: 
+All workspaces inside a {platforms-namespace} use the same Persistent Volume Claim (PVC) as the default data storage when storing data such as the following in their declared volumes:
 
 * projects
 * workspace logs
@@ -38,9 +38,9 @@ If there are several nodes, you can use the `common` strategy, but:
 
 * The workspace PVC access mode must be reconfigured to `ReadWriteMany` (RWM), so multiple nodes can use this PVC simultaneously.
 
-* Only one workspace in the same {orch-namespace} may be running. See xref:installation-guide:configuring-namespace-strategies.adoc[].
+* Only one workspace in the same {orch-namespace} may be running. See xref:installation-guide:run-several-workspaces-at-a-time.adoc[].
 
-The `common` PVC strategy is not suitable for large multi-node clusters. Therefore, it is best to use it in single-node clusters. However, in combination with `per-workspace` {orch-namespace} strategy, the `common` PVC strategy is usable for clusters with around 75 nodes. The PVC used in this strategy must be large enough to accommodate all projects since there is a risk of the event, in which one project depletes the resources of others. 
+The `common` PVC strategy is not suitable for large multi-node clusters. Therefore, it is best to use it in single-node clusters. However, in combination with `per-workspace` {orch-namespace} strategy, the `common` PVC strategy is usable for clusters with around 75 nodes. The PVC used in this strategy must be large enough to accommodate all projects since there is a risk of the event, in which one project depletes the resources of others.
 
 [id="the-per-workspace-pvc-strategy_{context}"]
 == The `per-workspace` PVC strategy
@@ -51,7 +51,7 @@ The `per-workspace` strategy is similar to the `common` PVC strategy. The only d
 * workspace logs
 * additional Volumes defined by a user
 
-It’s a strategy when {prod-short} keeps its workspace data in assigned PVs that are allocated by a single PVC. 
+It’s a strategy when {prod-short} keeps its workspace data in assigned PVs that are allocated by a single PVC.
 
 The `per-workspace` PVC strategy is the most universal strategy out of the PVC strategies available and acts as a proper option for large multi-node clusters with a higher amount of users. Using the `per-workspace` PVC strategy, users can run multiple workspaces simultaneously, results in more PVCs being created.
 
@@ -60,7 +60,7 @@ The `per-workspace` PVC strategy is the most universal strategy out of the PVC s
 
 When using the `unique `PVC strategy, every {prod-short} Volume of a workspace has its own PVC. This means that workspace PVCs are:
 
-Created when a workspace starts for the first time. 
+Created when a workspace starts for the first time.
 Deleted when a corresponding workspace is deleted.
 
 User-defined PVCs are created with the following specifics:

modules/installation-guide/nav.adoc

@@ -32,6 +32,7 @@
 
 ** xref:advanced-configuration-options-for-the-che-server-component.adoc[]
 ** xref:configuring-namespace-strategies.adoc[]
+** xref:run-several-workspaces-at-a-time.adoc[]
 ** xref:configuring-workspace-exposure-strategies.adoc[]
 ** xref:configuring-workspaces-nodeselector.adoc[]
 ** xref:configuring-che-hostname.adoc[]

modules/installation-guide/pages/run-several-workspaces-at-a-time.adoc

@@ -0,0 +1,8 @@
+[id="run-several-workspaces-at-a-time"]
+// = Run several workspaces at a time
+:navtitle: Run more than one workspace at a time
+:keywords: installation-guide, run-workspaces
+:page-aliases: .:run-several-workspaces-at-a-time
+
+include::partial$proc_run-several-workspaces-at-a-time.adoc[]
+

modules/installation-guide/partials/assembly_advanced-configuration.adoc

@@ -16,6 +16,8 @@ The next sections describe some specific user stories.
 
 * xref:configuring-namespace-strategies.adoc[]
 
+* xref:run-several-workspaces-at-a-time.adoc[]
+
 * xref:configuring-workspaces-nodeselector.adoc[]
 
 * xref:configuring-che-hostname.adoc[]

modules/installation-guide/partials/proc_configuring-namespace-strategies.adoc

@@ -10,20 +10,8 @@ The {platforms-namespace} strategies are configured using the `CHE_INFRA_KUBERNE
 
 WARNING: `CHE_INFRA_KUBERNETES_NAMESPACE` and `CHE_INFRA_OPENSHIFT_PROJECT` are legacy variables. Keep these variables unset for a new installations. Changing these variables during an update can lead to data loss.
 
-[IMPORTANT]
-====
-To run more than one workspace at a time:
-
-1. Remove the limit of concurrently running workspaces per user:
+WARNING: Only one workspace in the same {orch-namespace} may be running by default. See xref:installation-guide:run-several-workspaces-at-a-time.adoc[].
 
-ifeval::["{project-context}" == "che"]
-* For Helm Chart deployments: set the `.global.workspace.number` parameter to `-1`.
-endif::[]
-
-* For Operator deployments: set the `spec.server.cheCustomProperties.CHE_LIMITS_USER_WORKSPACE_RUN_COUNT` variable of the CheCluster Custom Resource (CR) to `-1`.
-
-2. Use `per-workspace` or `unique` PVC strategy. To use `common` PVC strategy configure the persistent volumes to use `ReadWriteMany` access mode.
-====
 
 == One {orch-namespace} per workspace strategy
 

modules/installation-guide/partials/proc_run-several-workspaces-at-a-time.adoc

@@ -0,0 +1,33 @@
+
+[id="run-several-workspaces-at-a-time_{context}"]
+= Run more than one workspaces at a time
+
+This procedure describes how to run more than once workspace at a time.
+
+.Prerequisites
+
+* The `{orch-cli}` tool is available.
+* An instance of {prod-short} running in {orch-name}.
+
+.Procedure
+
+. Remove the limit of concurrently running workspaces per user:
+
+* For Operator deployments:
++
+[subs="+quotes,+attributes"]
+----
+$ {orch-cli} patch checluster {prod-checluster} -n {prod-namespace} --type merge \
+-p '{ "spec": { "server": {"customCheProperties": {"CHE_LIMITS_USER_WORKSPACE_RUN_COUNT": "-1"} } }}'
+----
+ifeval::["{project-context}" == "che"]
+* For Helm Chart deployments:
++
+[subs="+quotes,+attributes"]
+----
+$ helm upgrade che -n {prod-namespace} --set global.workspace.number=-1
+----
+endif::[]
+
+. Use `per-workspace` or `unique` PVC strategy. To use `common` PVC strategy configure the persistent volumes to use `ReadWriteMany` access mode.
+