Merge pull request #55356 from aireilly/OCPBUGS-6802

mburke5678 · web-flow · commit 3ad5f8996138 · 2023-01-31T10:45:59.000-05:00
OCPBUGS-6802 - Remedy unclear topic titles for GitOps ZTP worker nodes
diff --git a/modules/ztp-adding-worker-nodes.adoc b/modules/ztp-adding-worker-nodes.adoc
@@ -1,27 +1,26 @@
 // Module included in the following assemblies:
-// Epic CNF-5335 (4.11), Story TELCODOCS-643
-// scalability_and_performance/ztp-deploying-disconnected.adoc
+//
+// * scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc
 
 :_content-type: PROCEDURE
 [id="ztp-additional-worker-sno-proc_{context}"]
-= Adding worker nodes to {sno} clusters
-include::../_attributes/common-attributes.adoc[]
+= Adding worker nodes to {sno} clusters with GitOps ZTP
 
-You can add one or more worker nodes to existing {sno} clusters to increase CPU resources.
+You can add one or more worker nodes to existing {sno} clusters to increase available CPU resources in the cluster.
 
 .Prerequisites
 
-* Install and configure {rh-rhacm} 2.6 or later running on {product-title} 4.11 or later on a bare-metal cluster
-* Install {cgu-operator-full}
-* Install OpenShift GitOps Operator
-* Run {product-title} 4.12 or later in the zero touch provisioning (ZTP) container
-* Deploy an {sno} cluster through ZTP
+* Install and configure {rh-rhacm} 2.6 or later in an {product-title} 4.11 or later bare-metal hub cluster
+* Install {cgu-operator-full} in the hub cluster
+* Install {gitops-title} in the hub cluster
+* Use the GitOps ZTP `ztp-site-generate` container image version 4.12 or later
+* Deploy a managed {sno} cluster with GitOps ZTP
 * Configure the Central Infrastructure Management as described in the {rh-rhacm} documentation
 * Configure the DNS serving the cluster to resolve the internal API endpoint `api-int.<cluster_name>.<base_domain>`
 
 .Procedure
 
-. If you deployed your cluster using the `example-sno.yaml` `SiteConfig` manifest, add your new worker node to the `spec.clusters['example-sno'].nodes` list:
+. If you deployed your cluster by using the `example-sno.yaml` `SiteConfig` manifest, add your new worker node to the `spec.clusters['example-sno'].nodes` list:
 +
 [source,yaml]
 ----
@@ -79,13 +78,13 @@ metadata:
 type: Opaque
 ----
 
-. Commit the changes in Git, and then push to the Git repository being monitored by the GitOps ZTP ArgoCD application.
-
+. Commit the changes in Git, and then push to the Git repository that is being monitored by the GitOps ZTP ArgoCD application.
++
 When the ArgoCD `cluster` application synchronizes, two new manifests appear on the hub cluster generated by the ZTP plugin:
-
++
 * `BareMetalHost`
 * `NMStateConfig`
-
++
 [IMPORTANT]
 ====
 The `cpuset` field should not be configured for the worker node. Workload partitioning for worker nodes is added through management policies after the node installation is complete.
@@ -95,31 +94,29 @@ The `cpuset` field should not be configured for the worker node. Workload partit
 
 You can monitor the installation process in several ways.
 
-. Check if the preprovisioning images are created by running the following command:
+* Check if the preprovisioning images are created by running the following command:
 +
 [source,terminal]
 ----
 $ oc get ppimg -n example-sno
 ----
 +
 .Example output
-+
 [source,terminal]
 ----
 NAMESPACE       NAME            READY   REASON
 example-sno     example-sno     True    ImageCreated
 example-sno     example-node2   True    ImageCreated
 ----
 
-. Check the state of the bare-metal hosts:
+* Check the state of the bare-metal hosts:
 +
 [source,terminal]
 ----
 $ oc get bmh -n example-sno
 ----
 +
 .Example output
-+
 [source,terminal]
 ----
 NAME            STATE          CONSUMER   ONLINE   ERROR   AGE
@@ -128,15 +125,16 @@ example-node2   provisioning              true             4m50s <1>
 ----
 <1> The `provisioning` state indicates that node booting from the installation media is in progress.
 
-. Continuously monitor the installation process:
+* Continuously monitor the installation process:
+
+.. Watch the agent install process by running the following command:
 +
 [source,terminal]
 ----
 $ oc get agent -n example-sno --watch
 ----
 +
 .Example output
-+
 [source,terminal]
 ----
 NAME                                   CLUSTER   APPROVED   ROLE     STAGE
@@ -152,7 +150,7 @@ NAME                                   CLUSTER   APPROVED   ROLE     STAGE
 14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Done
 ----
 
-. When the worker node installation completes, its certificates are approved automatically. At this point, the worker appears in the `ManagedClusterInfo` status:
+.. When the worker node installation is finished, the worker node certificates are approved automatically. At this point, the worker appears in the `ManagedClusterInfo` status. Run the following command to see the status:
 +
 [source,terminal]
 ----
@@ -161,9 +159,8 @@ jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"
 ----
 +
 .Example output
-+
 [source,terminal]
 ----
 example-sno	[{"status":"True","type":"Ready"}]	{"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""}
 example-node2	[{"status":"True","type":"Ready"}]	{"node-role.kubernetes.io/worker":""}
-----
+----
diff --git a/modules/ztp-additional-worker-to-sno-cluster.adoc b/modules/ztp-additional-worker-to-sno-cluster.adoc
@@ -1,24 +1,23 @@
 // Module included in the following assemblies:
-// Epic CNF-5335 (4.11), Story TELCODOCS-643
-// scalability_and_performance/ztp-deploying-disconnected.adoc
+//
+// * scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc
+
 
 :_content-type: CONCEPT
 [id="ztp-additional-worker-sno_{context}"]
-= {sno-caps} cluster expansion with worker nodes
-include::../_attributes/common-attributes.adoc[]
+= Expanding {sno} clusters with GitOps ZTP
 
-When you add worker nodes to increase available CPU resources, the original {sno} cluster retains the control plane node role.
+You can expand {sno} clusters with GitOps ZTP. When you add worker nodes to {sno} clusters, the original {sno} cluster retains the control plane node role.
 
 [NOTE]
 ====
-Although there is no specified limit on the number of worker nodes that you can add, you must revaluate the reserved CPU allocation on the control plane node for the additional worker nodes.
+Although there is no specified limit on the number of worker nodes that you can add to a {sno} cluster, you must revaluate the reserved CPU allocation on the control plane node for the additional worker nodes.
 ====
 
-If workload partitioning is required on the worker node, the policies configuring the worker node must be deployed and remediated before installing the node. This way, the workload partitioning `MachineConfig` objects are rendered and associated with the `worker` `MachineConfig` pool before the `MachineConfig` ignition is downloaded by the installing worker node.
+If you require workload partitioning on the worker node, you must deploy and remediate the managed cluster policies on the hub cluster before installing the node. This way, the workload partitioning `MachineConfig` objects are rendered and associated with the `worker` `MachineConfig` pool before the GitOps ZTP workflow applies the `MachineConfig` ignition file to the worker node.
 
 The recommended procedure order is remediating policies, then installing the worker node.
 If you create the workload partitioning manifests after node installation, you must manually drain the node and delete all the pods managed by daemonsets. When the managing daemonsets create the new pods, the new pods undergo the workload partitioning process.
 
-:FeatureName: Adding worker nodes to {sno} clusters
-
+:FeatureName: Adding worker nodes to {sno} clusters with GitOps ZTP
 include::snippets/technology-preview.adoc[]
diff --git a/modules/ztp-worker-node-applying-du-profile.adoc b/modules/ztp-worker-node-applying-du-profile.adoc
@@ -1,11 +1,10 @@
 // Module included in the following assemblies:
-// Epic CNF-5335 (4.11), Story TELCODOCS-643
-// scalability_and_performance/ztp-deploying-disconnected.adoc
+//
+// * scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc
 
 :_content-type: CONCEPT
 [id="ztp-additional-worker-apply-du-profile_{context}"]
 = Applying profiles to the worker node
-include::../_attributes/common-attributes.adoc[]
 
 You can configure the additional worker node with a DU profile.
 
@@ -17,4 +16,4 @@ You can apply a RAN distributed unit (DU) profile to the worker node cluster usi
 * `ns.yaml`
 * `kustomization.yaml`
 
-Configuring the DU profile on the worker node is considered an upgrade. To initiate the upgrade flow, you must update the existing policies or create additional ones. Then, you must create a `ClusterGroupUpgrade` CR to reconcile the policies in the group of clusters.
+Configuring the DU profile on the worker node is considered an upgrade. To initiate the upgrade flow, you must update the existing policies or create additional ones. Then, you must create a `ClusterGroupUpgrade` CR to reconcile the policies in the group of clusters.
diff --git a/modules/ztp-worker-node-daemon-selector-compatibility.adoc b/modules/ztp-worker-node-daemon-selector-compatibility.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
-// Epic CNF-5335 (4.11), Story TELCODOCS-643
-// scalability_and_performance/ztp-deploying-disconnected.adoc
+//
+// * scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc
 
 :_content-type: PROCEDURE
 [id="ztp-additional-worker-daemon-selector-comp_{context}"]
@@ -65,4 +65,4 @@ spec:
 Changing the `daemonNodeSelector` field causes temporary PTP synchronization loss and SR-IOV connectivity loss.
 ====
 
-. Commit the changes in Git, and then push to the Git repository being monitored by the GitOps ZTP ArgoCD application.
+. Commit the changes in Git, and then push to the Git repository being monitored by the GitOps ZTP ArgoCD application.
diff --git a/modules/ztp-worker-node-node-selector-compatibility.adoc b/modules/ztp-worker-node-node-selector-compatibility.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
-// Epic CNF-5335 (4.11), Story TELCODOCS-643
-// scalability_and_performance/ztp-deploying-disconnected.adoc
+//
+// * scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc
 
 :_content-type: CONCEPT
 [id="ztp-additional-worker-node-selector-comp_{context}"]
 = PTP and SR-IOV node selector compatibility
 
-The PTP configuration resources and SR-IOV network node policies use `node-role.kubernetes.io/master: ""` as the node selector. If the additional worker nodes have the same NIC configuration as the control plane node, the policies used to configure the control plane node can be reused for the worker nodes. However, the node selector must be changed to select both node types, for example with the `"node-role.kubernetes.io/worker"` label.
+The PTP configuration resources and SR-IOV network node policies use `node-role.kubernetes.io/master: ""` as the node selector. If the additional worker nodes have the same NIC configuration as the control plane node, the policies used to configure the control plane node can be reused for the worker nodes. However, the node selector must be changed to select both node types, for example with the `"node-role.kubernetes.io/worker"` label.
diff --git a/modules/ztp-worker-node-preparing-policies.adoc b/modules/ztp-worker-node-preparing-policies.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
-// Epic CNF-5335 (4.11), Story TELCODOCS-643
-// scalability_and_performance/ztp-deploying-disconnected.adoc
+//
+// * scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc
 
 :_content-type: PROCEDURE
 [id="ztp-additional-worker-policies_{context}"]
@@ -125,4 +125,4 @@ spec:
   remediationStrategy:
     maxConcurrency: 1
 EOF
-----
+----
diff --git a/scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc b/scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-You can add one or more worker nodes to an existing {sno} cluster to increase CPU resources used by the original {sno} control plane node. The addition of worker nodes does not require any downtime for the existing {sno}.
+You can add one or more worker nodes to an existing {sno} cluster with GitOps ZTP. Adding worker nodes does not require any downtime for the existing {sno}.
 
 [role="_additional-resources"]
 .Additional resources
