Merge pull request #47284 from aireilly/adding-sno-variable

pneedle-rh · web-flow · commit 62d07891ddbb · 2022-07-05T10:58:35.000+01:00
"single-node OpenShift"  - Adding {sno} variables and updating existing incorrect references
diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc
@@ -132,3 +132,5 @@ endif::[]
 :ibmzProductName: IBM Z
 // Red Hat Quay Container Security Operator
 :rhq-cso: Red Hat Quay Container Security Operator
+:sno: single-node Openshift
+:sno-caps: Single-node Openshift
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -1511,7 +1511,7 @@ Topics:
     File: osdk-working-bundle-images
   - Name: Validating Operators using the scorecard
     File: osdk-scorecard
-  - Name: High-availability or single node cluster detection and support
+  - Name: High-availability or single-node cluster detection and support
     File: osdk-ha-sno
   - Name: Configuring built-in monitoring with Prometheus
     File: osdk-monitoring-prometheus
@@ -2233,13 +2233,13 @@ Topics:
 - Name: Creating a performance profile
   File: cnf-create-performance-profiles
   Distros: openshift-origin,openshift-enterprise
-- Name: Deploying distributed units manually on single node OpenShift
+- Name: Deploying distributed units manually on single-node OpenShift
   File: ztp-configuring-single-node-cluster-deployment-during-installation
   Distros: openshift-origin,openshift-enterprise
 - Name: Provisioning and deploying a distributed unit (DU)
   File: cnf-provisioning-and-deploying-a-distributed-unit
   Distros: openshift-webscale
-- Name: Workload partitioning on single node OpenShift
+- Name: Workload partitioning on single-node OpenShift
   File: sno-du-enabling-workload-partitioning-on-single-node-openshift
   Distros: openshift-origin,openshift-enterprise
 - Name: Deploying distributed units at scale in a disconnected environment
diff --git a/installing/installing-preparing.adoc b/installing/installing-preparing.adoc
@@ -89,7 +89,7 @@ endif::[]
 
 ////
 [id="installing-preparing-single-node"]
-=== Are you installing single node clusters at the edge?
+=== Are you installing single-node clusters at the edge?
 
 You can use the assisted installer to deploy xref:../installing/installing_sno/install-sno-installing-sno.adoc#installing-sno[single node] clusters for edge workloads.
 ////
diff --git a/modules/cnf-du-configuring-workload-partitioning.adoc b/modules/cnf-du-configuring-workload-partitioning.adoc
@@ -17,4 +17,4 @@ are correctly scheduled to run on the management CPU partition.
 
 . For pods and namespaces that are correctly annotated, the CPU request values are zeroed out and converted to `<workload-type>.workload.openshift.io/cores`. This modified resource allows the pods to be constrained to the restricted CPUs.
 
-. The single node cluster starts with management components constrained to a subset of available CPUs.
+. The single-node cluster starts with management components constrained to a subset of available CPUs.
diff --git a/modules/cnf-du-management-pods.adoc b/modules/cnf-du-management-pods.adoc
@@ -6,7 +6,7 @@
 
 = Cluster Management pods
 
-For the purposes of achieving 2-core (4 HT CPU) installation of single node clusters, the set of pods that are considered _management_ are limited to:
+For the purposes of achieving 2-core (4 HT CPU) installation of single-node clusters, the set of pods that are considered _management_ are limited to:
 
 * Core Operators
 * Day 2 Operators
diff --git a/modules/cnf-du-partitioning-management-workloads.adoc b/modules/cnf-du-partitioning-management-workloads.adoc
@@ -14,18 +14,18 @@ number of CPUs within the host.
 
 Server resources installed at the edge, such as cores, are expensive and limited. Application workloads require nearly all cores and the resources consumed by infrastructure is a key reason for the selection of a vRAN infrastructure. A hypothetical distributed unit (DU) example is an unusually resource-intensive workload, typically requiring 20 dedicated cores. Partitioning management workloads mitigates much of this activity by separating management tasks from normal workloads.
 
-When you use workload partitioning, the CPU resources used by {product-title} for cluster management are isolated to a partitioned set of CPU resources on a single node cluster with a DU profile applied. This falls broadly into two categories:
+When you use workload partitioning, the CPU resources used by {product-title} for cluster management are isolated to a partitioned set of CPU resources on a single-node cluster with a DU profile applied. This falls broadly into two categories:
 
 * Isolates cluster management functions to the defined number of CPUs. All cluster management functions operate solely on that `cpuset`.
 
 * Tunes the cluster configuration (with the applied DU profile) so the actual CPU usage fits within the assigned `cpuset`.
 
 [NOTE]
 ====
-This feature is only available on single node cluster in this release.
+This feature is only available on {sno} in this release.
 ====
 
-The minimum number of reserved CPUs required for the management partition for a single node cluster is four CPU HTs. Inclusion of Operators or workloads outside of the set of accepted management pods requires additional CPU HTs.
+The minimum number of reserved CPUs required for the management partition for a single-node cluster is four CPU HTs. Inclusion of Operators or workloads outside of the set of accepted management pods requires additional CPU HTs.
 
 Workload partitioning isolates the workloads away from the non-management workloads using the normal scheduling capabilities of Kubernetes to manage the number of pods that can be placed onto those cores, and avoids mixing cluster management workloads and user workloads.
 
diff --git a/modules/cnf-performing-end-to-end-tests-for-platform-verification.adoc b/modules/cnf-performing-end-to-end-tests-for-platform-verification.adoc
@@ -253,9 +253,9 @@ $ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registr
 ----
 
 [id="cnf-performing-end-to-end-tests-running-in-single-node-cluster_{context}"]
-== Running in a single node cluster
+== Running in a single-node cluster
 
-Running tests on a single node cluster causes the following limitations to be imposed:
+Running tests on a single-node cluster causes the following limitations to be imposed:
 
 * Longer timeouts for certain tests, including SR-IOV and SCTP tests
 * Tests requiring master and worker nodes are skipped
diff --git a/modules/cnf-running-the-performance-creator-profile-offline.adoc b/modules/cnf-running-the-performance-creator-profile-offline.adoc
@@ -219,7 +219,7 @@ The Performance Profile Creator arguments are shown in the Performance Profile C
 * `mcp-name`
 * `rt-kernel`
 
-The `mcp-name` argument in this example is set to `worker-cnf` based on the output of the command `oc get mcp`. For Single Node OpenShift (SNO) use `--mcp-name=master`.
+The `mcp-name` argument in this example is set to `worker-cnf` based on the output of the command `oc get mcp`. For {sno} use `--mcp-name=master`.
 ====
 
 . Review the created YAML file:
diff --git a/modules/cnf-running-the-performance-creator-profile.adoc b/modules/cnf-running-the-performance-creator-profile.adoc
@@ -120,7 +120,7 @@ The Performance Profile Creator arguments are shown in the Performance Profile C
 * `mcp-name`
 * `rt-kernel`
 
-The `mcp-name` argument in this example is set to `worker-cnf` based on the output of the command `oc get mcp`. For Single Node OpenShift (SNO) use `--mcp-name=master`.
+The `mcp-name` argument in this example is set to `worker-cnf` based on the output of the command `oc get mcp`. For {sno} use `--mcp-name=master`.
 ====
 
 . Review the created YAML file:
diff --git a/modules/install-sno-about-installing-on-a-single-node.adoc b/modules/install-sno-about-installing-on-a-single-node.adoc
@@ -6,9 +6,9 @@
 [id="install-sno-about-installing-on-a-single-node_{context}"]
 = About OpenShift on a single node
 
-You can create a single node cluster with standard installation methods. {product-title} on a single node is a specialized installation that requires the creation of a special ignition configuration ISO. The primary use case is for edge computing workloads, including intermittent connectivity, portable clouds, and 5G radio access networks (RAN) close to a base station. The major tradeoff with an installation on a single node is the lack of high availability.
+You can create a single-node cluster with standard installation methods. {product-title} on a single node is a specialized installation that requires the creation of a special ignition configuration ISO. The primary use case is for edge computing workloads, including intermittent connectivity, portable clouds, and 5G radio access networks (RAN) close to a base station. The major tradeoff with an installation on a single node is the lack of high availability.
 
 [IMPORTANT]
 ====
-The use of OpenShiftSDN with single-node OpenShift is deprecated. OVN-Kubernetes is the default networking solution for single-node OpenShift deployments.
-====
+The use of OpenShiftSDN with {sno} is deprecated. OVN-Kubernetes is the default networking solution for {sno} deployments.
+====
diff --git a/modules/install-sno-generating-the-discovery-iso-manually.adoc b/modules/install-sno-generating-the-discovery-iso-manually.adoc
@@ -105,7 +105,7 @@ sshKey: |
 +
 <4> Set the `metadata` name to the cluster name.
 +
-<5> Set the `networkType`. OVN-Kubernetes is the default networking for SNO. OpenShiftSDN is deprecated.
+<5> Set the `networkType`. OVN-Kubernetes is the default networking for {sno}. OpenShiftSDN is deprecated.
 +
 <6> Set the `clusterNetwork` CIDR.
 +
diff --git a/modules/nodes-nodes-rebooting-gracefully.adoc b/modules/nodes-nodes-rebooting-gracefully.adoc
@@ -10,9 +10,9 @@ Before rebooting a node, it is recommended to backup etcd data to avoid any data
 
 [NOTE]
 ====
-For Single Node OpenShift (SNO) clusters that require users to perform the `oc login` command rather than having the certificates in `kubeconfig` file to manage the cluster, the `oc adm` commands might not be available after cordoning and draining the node. This is because the `openshift-oauth-apiserver` pod is not running due to the cordon. You can use SSH to access the nodes as indicated in the following procedure.
+For {sno} clusters that require users to perform the `oc login` command rather than having the certificates in `kubeconfig` file to manage the cluster, the `oc adm` commands might not be available after cordoning and draining the node. This is because the `openshift-oauth-apiserver` pod is not running due to the cordon. You can use SSH to access the nodes as indicated in the following procedure.
 
-In an SNO cluster, pods cannot be rescheduled when cordoning and draining. However, doing so gives the pods, especially your workload pods, time to properly stop and release associated resources.
+In a {sno} cluster, pods cannot be rescheduled when cordoning and draining. However, doing so gives the pods, especially your workload pods, time to properly stop and release associated resources.
 ==== 
 
 .Procedure
@@ -73,7 +73,7 @@ In a moment, the node enters the `NotReady` state.
 +
 [NOTE]
 ====
-With some SNO clusters, the `oc` commands might not be available after you cordon and drain the node because the `openshift-oauth-apiserver` pod is not running. You can use SSH to connect to the node and perform the reboot.
+With some {sno} clusters, the `oc` commands might not be available after you cordon and drain the node because the `openshift-oauth-apiserver` pod is not running. You can use SSH to connect to the node and perform the reboot.
 
 [source,terminal]
 ----
@@ -95,7 +95,7 @@ $ oc adm uncordon <node1>
 +
 [NOTE]
 ====
-With some SNO clusters, the `oc` commands might not be available after you cordon and drain the node because the `openshift-oauth-apiserver` pod is not running. You can use SSH to connect to the node and uncordon it.
+With some {sno} clusters, the `oc` commands might not be available after you cordon and drain the node because the `openshift-oauth-apiserver` pod is not running. You can use SSH to connect to the node and uncordon it.
 
 [source,terminal]
 ----
diff --git a/modules/nw-sriov-configuring-operator.adoc b/modules/nw-sriov-configuring-operator.adoc
@@ -54,7 +54,7 @@ By default, this field is not set and the Operator deploys the SR-IOV Network Co
 |Specifies whether to disable the node draining process or enable the node draining process when you apply a new policy to configure the NIC on a node.
 Setting this field to `true` facilitates software development and installing {product-title} on a single node. By default, this field is not set.
 
-For single node clusters, set this field to `true` after installing the Operator. This field must remain set to `true`.
+For single-node clusters, set this field to `true` after installing the Operator. This field must remain set to `true`.
 
 |`spec.enableInjector`
 |`boolean`
diff --git a/modules/nw-sriov-installing-operator.adoc b/modules/nw-sriov-installing-operator.adoc
@@ -158,5 +158,5 @@ $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=
 +
 [NOTE]
 ====
-For the Single Node OpenShift (SNO) cluster, the annotation `workload.openshift.io/allowed=management` is required for the namespace.
+For {sno} clusters, the annotation `workload.openshift.io/allowed=management` is required for the namespace.
 ====
diff --git a/modules/osdk-ha-sno-api.adoc b/modules/osdk-ha-sno-api.adoc
@@ -10,7 +10,7 @@
 
 In the Infrastructure API, the `infrastructureTopology` status expresses the expectations for infrastructure services that do not run on control plane nodes, usually indicated by a node selector for a `role` value other than `master`. The `controlPlaneTopology` status expresses the expectations for Operands that normally run on control plane nodes.
 
-The default setting for either status is `HighlyAvailable`, which represents the behavior Operators have in multiple node clusters. The `SingleReplica` setting is used in single node clusters, also known as Single Node OpenShift (SNO), and indicates that Operators should not configure their Operands for high-availability operation.
+The default setting for either status is `HighlyAvailable`, which represents the behavior Operators have in multiple node clusters. The `SingleReplica` setting is used in single-node clusters, also known as {sno}, and indicates that Operators should not configure their Operands for high-availability operation.
 
 The {product-title} installer sets the `controlPlaneTopology` and `infrastructureTopology` status fields based on the replica counts for the cluster when it is created, according to the following rules:
 
diff --git a/modules/sno-du-applying-the-distributed-unit-configuration-to-sno.adoc b/modules/sno-du-applying-the-distributed-unit-configuration-to-sno.adoc
@@ -4,9 +4,9 @@
 
 :_content-type: CONCEPT
 [id="sno-du-applying-the-distributed-unit-configuration-to-sno_{context}"]
-= Applying the distributed unit (DU) configuration to a single node cluster
+= Applying the distributed unit (DU) configuration to a {sno} cluster
 
-Perform the following tasks to configure a single node cluster for a DU:
+Perform the following tasks to configure a single-node cluster for a DU:
 
 * Apply the required extra installation manifests at installation time.
 
diff --git a/modules/sno-du-applying-the-extra-installation-manifests.adoc b/modules/sno-du-applying-the-extra-installation-manifests.adoc
@@ -6,7 +6,7 @@
 [id="sno-du-applying-the-extra-installation-manifests_{context}"]
 = Applying the extra installation manifests
 
-To apply the distributed unit (DU) configuration to the single node cluster, the following
+To apply the distributed unit (DU) configuration to the single-node cluster, the following
 extra installation manifests need to be included during installation:
 
 * Enable workload partitioning.
diff --git a/modules/sno-du-configuring-the-distributed-units.adoc b/modules/sno-du-configuring-the-distributed-units.adoc
@@ -8,6 +8,6 @@
 
 This section describes a set of configurations for an {product-title} cluster so that it meets the feature and performance requirements necessary for running a distributed unit (DU) application. Some of this content must be applied during installation and other configurations can be applied post-install.
 
-After you have installed the single-node DU, further configuration is needed to enable the platform to carry a DU workload.
+After you have installed the {sno} DU, further configuration is needed to enable the platform to carry a DU workload.
 
 The configurations in this section are applied to the cluster after installation in order to configure the cluster for DU workloads.
diff --git a/modules/sno-du-enabling-workload-partitioning.adoc b/modules/sno-du-enabling-workload-partitioning.adoc
@@ -6,7 +6,7 @@
 [id="sno-du-enabling-workload-partitioning_{context}"]
 = Enabling workload partitioning
 
-A key feature to enable as part of a single node installation is workload partitioning. This limits the cores allowed to run platform services, maximizing the CPU core for application payloads. You must configure workload partitioning at cluster installation time.
+A key feature to enable as part of a {sno} installation is workload partitioning. This limits the cores allowed to run platform services, maximizing the CPU core for application payloads. You must configure workload partitioning at cluster installation time.
 
 [NOTE]
 ====
diff --git a/modules/virt-about-vm-templates.adoc b/modules/virt-about-vm-templates.adoc
@@ -26,5 +26,5 @@ You can also select the *Create Virtual Machine Template* wizard directly and cr
 
 [IMPORTANT]
 ====
-Due to differences in storage behavior, some virtual machine templates are incompatible with SNO. To ensure compatibility, do not set the `evictionStrategy` field for any templates or virtual machines that use data volumes or storage profiles.
+Due to differences in storage behavior, some virtual machine templates are incompatible with {sno}. To ensure compatibility, do not set the `evictionStrategy` field for any templates or virtual machines that use data volumes or storage profiles.
 ====
diff --git a/modules/ztp-about-ztp-and-distributed-units-on-single-node-openshift-clusters.adoc b/modules/ztp-about-ztp-and-distributed-units-on-single-node-openshift-clusters.adoc
@@ -32,7 +32,7 @@ CRs are as follows:
 | Custom Resource | Description
 
 |Namespace
-|Namespace for the managed single node cluster.
+|Namespace for the managed single-node cluster.
 
 |BMCSecret CR
 |Credentials for the host BMC.
@@ -41,7 +41,7 @@ CRs are as follows:
 |Pull secret for the disconnected registry.
 
 |AgentClusterInstall
-|Specifies the single node cluster's configuration such as networking, number of supervisor (control plane) nodes, and so on.
+|Specifies the single-node cluster's configuration such as networking, number of supervisor (control plane) nodes, and so on.
 
 |ClusterDeployment
 |Defines the cluster name, domain, and other details.
diff --git a/modules/ztp-ai-install-ocp-clusters-on-bare-metal.adoc b/modules/ztp-ai-install-ocp-clusters-on-bare-metal.adoc
@@ -8,7 +8,7 @@
 
 The Assisted Installer Service (AIS) deploys {product-title} clusters. {rh-rhacm-first} ships with AIS. AIS is deployed when you enable the MultiClusterHub Operator on the {rh-rhacm} hub cluster.
 
-For distributed units (DUs), {rh-rhacm} supports {product-title} deployments that run on a single bare-metal host. The single node cluster acts as both a control plane and a worker node.
+For distributed units (DUs), {rh-rhacm} supports {product-title} deployments that run on a single bare-metal host. The single-node cluster acts as both a control plane and a worker node.
 
 .Prerequisites
 
diff --git a/modules/ztp-creating-siteconfig-custom-resources.adoc b/modules/ztp-creating-siteconfig-custom-resources.adoc
@@ -151,7 +151,7 @@ spec:
 +
 <1> The name of the ClusterImageSet custom resource used to install {product-title} on the bare-metal host.
 <2> A block of IPv4 or IPv6 addresses in CIDR notation used for communication among cluster nodes.
-<3> A block of IPv4 or IPv6 addresses in CIDR notation used for the target bare-metal host external communication. Also used to determine the API and Ingress VIP addresses when provisioning DU single node clusters.
+<3> A block of IPv4 or IPv6 addresses in CIDR notation used for the target bare-metal host external communication. Also used to determine the API and Ingress VIP addresses when provisioning DU single-node clusters.
 <4> A block of IPv4 or IPv6 addresses in CIDR notation used for cluster services internal communication.
 <5> Entered as plain text. You can use the public key to SSH into the node after it has finished installing.
 +
diff --git a/modules/ztp-single-node-clusters.adoc b/modules/ztp-single-node-clusters.adoc
@@ -5,18 +5,18 @@
 :_content-type: CONCEPT
 [id="ztp-single-node-clusters_{context}"]
 
-= Single node clusters
+= Single-node clusters
 
-You use zero touch provisioning (ZTP) to deploy single node clusters to run distributed units (DUs) on small hardware footprints at disconnected
-far edge sites. A single node cluster runs {product-title} on top of one bare-metal host, hence the single node. Edge servers contain a single node with supervisor functions and worker functions on the same host that are deployed at low bandwidth or disconnected edge sites.
+You use zero touch provisioning (ZTP) to deploy {sno} clusters to run distributed units (DUs) on small hardware footprints at disconnected
+far edge sites. A single-node cluster runs {product-title} on top of one bare-metal host, hence the single node. Edge servers contain a single node with supervisor functions and worker functions on the same host that are deployed at low bandwidth or disconnected edge sites.
 
 {product-title} is configured on the single node to use workload partitioning. Workload partitioning separates cluster management workloads from
 user workloads and can run the cluster management workloads on a reserved set of CPUs.
 Workload partitioning is useful for resource-constrained environments, such as single-node production deployments,
 where you want to reserve most of the CPU resources for user workloads and configure {product-title} to use fewer CPU resources within the host.
 
-A single node cluster hosting a DU application on a node is divided into the following configuration categories:
+A single-node cluster hosting a DU application on a node is divided into the following configuration categories:
 
-* Common - Values are the same for all single node cluster sites managed by a hub cluster.
+* Common - Values are the same for all single-node cluster sites managed by a hub cluster.
 * Pools of sites - Common across a pool of sites where a pool size can be 1 to _n_.
 * Site specific - Likely specific to a site with no overlap with other sites, for example, a vlan.
diff --git a/modules/ztp-ztp-building-blocks.adoc b/modules/ztp-ztp-building-blocks.adoc
diff --git a/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc b/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc
diff --git a/operators/operator_sdk/osdk-ha-sno.adoc b/operators/operator_sdk/osdk-ha-sno.adoc
diff --git a/scalability_and_performance/sno-du-enabling-workload-partitioning-on-single-node-openshift.adoc b/scalability_and_performance/sno-du-enabling-workload-partitioning-on-single-node-openshift.adoc
diff --git a/scalability_and_performance/ztp-configuring-single-node-cluster-deployment-during-installation.adoc b/scalability_and_performance/ztp-configuring-single-node-cluster-deployment-during-installation.adoc
diff --git a/updating/index.adoc b/updating/index.adoc
diff --git a/updating/preparing-eus-eus-upgrade.adoc b/updating/preparing-eus-eus-upgrade.adoc
diff --git a/virt/install/preparing-cluster-for-virt.adoc b/virt/install/preparing-cluster-for-virt.adoc
diff --git a/virt/virtual_machines/virt-create-vms.adoc b/virt/virtual_machines/virt-create-vms.adoc

Original file line number	Diff line number	Diff line change
`@@ -17,4 +17,4 @@ are correctly scheduled to run on the management CPU partition.`
`17`	`17`
`18`	`18`	. For pods and namespaces that are correctly annotated, the CPU request values are zeroed out and converted to `<workload-type>.workload.openshift.io/cores`. This modified resource allows the pods to be constrained to the restricted CPUs.
`19`	`19`
`20`		`-. The single node cluster starts with management components constrained to a subset of available CPUs.`
	`20`	`+. The single-node cluster starts with management components constrained to a subset of available CPUs.`