Merge pull request #59196 from aireilly/chore-fix-ztp-refs

Author: adellape

architecture/mce-overview-ocp.adoc

@@ -19,15 +19,15 @@ When you enable multicluster engine on {product-title}, you gain the following c
 * xref:../architecture/control-plane.adoc#hosted-control-planes-overview_control-plane[Hosted control planes], which is a feature that is based on the HyperShift project. With a centralized hosted control plane, you can operate {product-title} clusters in a hyperscale manner.
 * Hive, which provisions self-managed {product-title} clusters to the hub and completes the initial configurations for those clusters.
 * klusterlet agent, which registers managed clusters to the hub.
-* Infrastructure Operator, which manages the deployment of the Assisted Service to orchestrate on-premise bare metal and vSphere installations of {product-title}, such as SNO on bare metal. The Infrastructure Operator includes xref:../scalability_and_performance/ztp_far_edge/ztp-deploying-far-edge-clusters-at-scale.adoc#ztp-challenges-of-far-edge-deployments_ztp-deploying-far-edge-clusters-at-scale[zero touch provisioning (ZTP)], which fully automates cluster creation on bare metal and vSphere provisioning with GitOps workflows to manage deployments and configuration changes.
+* Infrastructure Operator, which manages the deployment of the Assisted Service to orchestrate on-premise bare metal and vSphere installations of {product-title}, such as SNO on bare metal. The Infrastructure Operator includes xref:../scalability_and_performance/ztp_far_edge/ztp-deploying-far-edge-clusters-at-scale.adoc#ztp-challenges-of-far-edge-deployments_ztp-deploying-far-edge-clusters-at-scale[{ztp-first}], which fully automates cluster creation on bare metal and vSphere provisioning with GitOps workflows to manage deployments and configuration changes.
 * Open cluster management, which provides resources to manage Kubernetes clusters.
 
 The multicluster engine is included with your {product-title} support subscription and is delivered separately from the core payload. To start to use multicluster engine, you deploy the {product-title} cluster and then install the operator. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.7/html/clusters/cluster_mce_overview#mce-install-intro[the installation documentation].
 
 [id="mce-on-rhacm"]
 == Cluster management with Red Hat Advanced Cluster Management
 
-If you need cluster management capabilities beyond what {product-title} with multicluster engine can provide, consider Red Hat Advanced Cluster Management. The multicluster engine is an integral part of Red Hat Advanced Cluster Management and is enabled by default. 
+If you need cluster management capabilities beyond what {product-title} with multicluster engine can provide, consider Red Hat Advanced Cluster Management. The multicluster engine is an integral part of Red Hat Advanced Cluster Management and is enabled by default.
 
 [id="mce-additional-resources-ocp"]
 == Additional resources

installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc

@@ -41,4 +41,4 @@ include::modules/sample-ztp-custom-resources.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* See xref:../../scalability_and_performance/ztp_far_edge/ztp-deploying-far-edge-clusters-at-scale.adoc#ztp-deploying-far-edge-clusters-at-scale[Challenges of the network far edge] to learn more about zero touch provisioning (ZTP).
+* See xref:../../scalability_and_performance/ztp_far_edge/ztp-deploying-far-edge-clusters-at-scale.adoc#ztp-deploying-far-edge-clusters-at-scale[Challenges of the network far edge] to learn more about {ztp-first}.

modules/about-ztp.adoc

@@ -4,13 +4,13 @@
 
 :_content-type: CONCEPT
 [id="about-ztp_{context}"]
-= Using ZTP to provision clusters at the network far edge
+= Using {ztp} to provision clusters at the network far edge
 
-{rh-rhacm-first} manages clusters in a hub-and-spoke architecture, where a single hub cluster manages many spoke clusters. Hub clusters running {rh-rhacm} provision and deploy the managed clusters by using zero touch provisioning (ZTP) and the assisted service that is deployed when you install {rh-rhacm}.
+{rh-rhacm-first} manages clusters in a hub-and-spoke architecture, where a single hub cluster manages many spoke clusters. Hub clusters running {rh-rhacm} provision and deploy the managed clusters by using {ztp-first} and the assisted service that is deployed when you install {rh-rhacm}.
 
 The assisted service handles provisioning of {product-title} on single node clusters, three-node clusters, or standard clusters running on bare metal.
 
-A high-level overview of using ZTP to provision and maintain bare-metal hosts with {product-title} is as follows:
+A high-level overview of using {ztp} to provision and maintain bare-metal hosts with {product-title} is as follows:
 
 * A hub cluster running {rh-rhacm} manages an {product-registry} that mirrors the {product-title} release images. {rh-rhacm} uses the {product-registry} to provision the managed clusters.
 
@@ -20,4 +20,4 @@ A high-level overview of using ZTP to provision and maintain bare-metal hosts wi
 
 Installing and deploying the clusters is a two-stage process, involving an initial installation phase, and a subsequent configuration phase. The following diagram illustrates this workflow:
 
-image::217_OpenShift_Zero_Touch_Provisioning_updates_1022_2.png[Using GitOps and ZTP to install and deploy managed clusters]
+image::217_OpenShift_Zero_Touch_Provisioning_updates_1022_2.png[Using GitOps and {ztp} to install and deploy managed clusters]

modules/agent-install-about-mirroring-for-disconnected-registry.adoc

@@ -49,7 +49,7 @@ Use the output of the command to update the `imageContentSources` field in the `
 
 The value must be the contents of the certificate file that you used for your mirror registry. The certificate file can be an existing, trusted certificate authority, or the self-signed certificate that you generated for the mirror registry.
 
-If you are using the optional method of the ZTP manifests, there are two mirror configuration files: `registries.conf` and `ca- bundle.crt` . These files must be added to the `mirror/directory` path to add the mirror configuration in the agent ISO image.
+If you are using the optional method of the {ztp} manifests, there are two mirror configuration files: `registries.conf` and `ca- bundle.crt` . These files must be added to the `mirror/directory` path to add the mirror configuration in the agent ISO image.
 
 You can create the `registries.conf` file from the output of either the `oc adm release mirror` or `oc mirror` command. The format of the `/etc/containers/registries.conf` file has changed . It is now version 2 and in TOML format.
 

modules/agent-install-networking.adoc

@@ -81,10 +81,10 @@ rendezvousIP: 192.168.111.80 <1>
 <6> Next hop address for the node traffic. This must be in the same subnet as the IP address set for the specified interface.
 
 +
-.. Optional method: ZTP manifests
+.. Optional method: {ztp} manifests
 
 +
-The optional method of the ZTP custom resources comprises 6 custom resources; you can configure static IPs in the `nmstateconfig.yaml` file.
+The optional method of the {ztp} custom resources comprises 6 custom resources; you can configure static IPs in the `nmstateconfig.yaml` file.
 
 +
 [source,yaml]

modules/agent-installer-configuring-fips-compliance.adoc

@@ -25,7 +25,7 @@ metadata:
 fips: True
 ----
 
-. Optional: If you are using the ZTP manifests, you must set the value of `fips` as `True` in the `Agent-install.openshift.io/install-config-overrides` field in the `agent-cluster-install.yaml` file:
+. Optional: If you are using the {ztp} manifests, you must set the value of `fips` as `True` in the `Agent-install.openshift.io/install-config-overrides` field in the `agent-cluster-install.yaml` file:
 
 +
 .Sample agent-cluster-install.yaml file

modules/cnf-topology-aware-lifecycle-manager-autocreate-cgu-cr-ztp.adoc

@@ -4,15 +4,15 @@
 
 :_content-type: PROCEDURE
 [id="talo-precache-autocreated-cgu-for-ztp_{context}"]
-= About the auto-created ClusterGroupUpgrade CR for ZTP
+= About the auto-created ClusterGroupUpgrade CR for {ztp}
 
-{cgu-operator} has a controller called `ManagedClusterForCGU` that monitors the `Ready` state of the `ManagedCluster` CRs on the hub cluster and creates the `ClusterGroupUpgrade` CRs for ZTP (zero touch provisioning).
+{cgu-operator} has a controller called `ManagedClusterForCGU` that monitors the `Ready` state of the `ManagedCluster` CRs on the hub cluster and creates the `ClusterGroupUpgrade` CRs for {ztp-first}.
 
-For any managed cluster in the `Ready` state without a `ztp-done` label applied, the `ManagedClusterForCGU` controller automatically creates a `ClusterGroupUpgrade` CR in the `ztp-install` namespace with its associated {rh-rhacm} policies that are created during the ZTP process. {cgu-operator} then remediates the set of configuration policies that are listed in the auto-created `ClusterGroupUpgrade` CR to push the configuration CRs to the managed cluster.
+For any managed cluster in the `Ready` state without a `ztp-done` label applied, the `ManagedClusterForCGU` controller automatically creates a `ClusterGroupUpgrade` CR in the `ztp-install` namespace with its associated {rh-rhacm} policies that are created during the {ztp} process. {cgu-operator} then remediates the set of configuration policies that are listed in the auto-created `ClusterGroupUpgrade` CR to push the configuration CRs to the managed cluster.
 
 If there are no policies for the managed cluster at the time when the cluster becomes `Ready`, a `ClusterGroupUpgrade` CR with no policies is created. Upon completion of the `ClusterGroupUpgrade` the managed cluster is labeled as `ztp-done`. If there are policies that you want to apply for that managed cluster, manually create a `ClusterGroupUpgrade` as a day-2 operation. 
 
-.Example of an auto-created `ClusterGroupUpgrade` CR for ZTP
+.Example of an auto-created `ClusterGroupUpgrade` CR for {ztp}
 
 [source,yaml]
 ----

modules/cnf-topology-aware-lifecycle-manager-operator-and-platform-update.adoc

@@ -11,8 +11,8 @@ You can perform a platform and an Operator update at the same time.
 .Prerequisites
 
 * Install the {cgu-operator-first}.
-* Update ZTP to the latest version.
-* Provision one or more managed clusters with ZTP.
+* Update {ztp-first} to the latest version.
+* Provision one or more managed clusters with {ztp}.
 * Log in as a user with `cluster-admin` privileges.
 * Create {rh-rhacm} policies in the hub cluster.
 

modules/cnf-topology-aware-lifecycle-manager-operator-update.adoc

@@ -11,8 +11,8 @@ You can perform an Operator update with the {cgu-operator}.
 .Prerequisites
 
 * Install the {cgu-operator-first}.
-* Update ZTP to the latest version.
-* Provision one or more managed clusters with ZTP.
+* Update {ztp-first} to the latest version.
+* Provision one or more managed clusters with {ztp}.
 * Mirror the desired index image, bundle images, and all Operator images referenced in the bundle images.
 * Log in as a user with `cluster-admin` privileges.
 * Create {rh-rhacm} policies in the hub cluster.
@@ -95,14 +95,14 @@ spec:
         source: certified-operators
 ----
 
-.. Remove the specified subscriptions channels in the common `PolicyGenTemplate` CR, if they exist. The default subscriptions channels from the ZTP image are used for the update.
+.. Remove the specified subscriptions channels in the common `PolicyGenTemplate` CR, if they exist. The default subscriptions channels from the {ztp} image are used for the update.
 +
 [NOTE]
 ====
-The default channel for the Operators applied through ZTP {product-version} is `stable`, except for the `performance-addon-operator`. As of {product-title} 4.11, the `performance-addon-operator` functionality was moved to the `node-tuning-operator`. For the 4.10 release, the default channel for PAO is `v4.10`. You can also specify the default channels in the common `PolicyGenTemplate` CR.
+The default channel for the Operators applied through {ztp} {product-version} is `stable`, except for the `performance-addon-operator`. As of {product-title} 4.11, the `performance-addon-operator` functionality was moved to the `node-tuning-operator`. For the 4.10 release, the default channel for PAO is `v4.10`. You can also specify the default channels in the common `PolicyGenTemplate` CR.
 ====
 
-.. Push the `PolicyGenTemplate` CRs updates to the ZTP Git repository.
+.. Push the `PolicyGenTemplate` CRs updates to the {ztp} Git repository.
 +
 ArgoCD pulls the changes from the Git repository and generates the policies on the hub cluster.
 

modules/cnf-topology-aware-lifecycle-manager-platform-update.adoc

@@ -11,8 +11,8 @@ You can perform a platform update with the {cgu-operator}.
 .Prerequisites
 
 * Install the {cgu-operator-first}.
-* Update ZTP to the latest version. 
-* Provision one or more managed clusters with ZTP.
+* Update {ztp-first} to the latest version.
+* Provision one or more managed clusters with {ztp}.
 * Mirror the desired image repository.
 * Log in as a user with `cluster-admin` privileges.
 * Create {rh-rhacm} policies in the hub cluster.
@@ -88,7 +88,7 @@ The `PolicyGenTemplate` CR generates two policies:
 
 * The `du-upgrade-platform-upgrade` policy is used to perform platform upgrade.
 
-.. Add the `du-upgrade.yaml` file contents to the `kustomization.yaml` file located in the ZTP Git repository for the `PolicyGenTemplate` CRs and push the changes to the Git repository.
+.. Add the `du-upgrade.yaml` file contents to the `kustomization.yaml` file located in the {ztp} Git repository for the `PolicyGenTemplate` CRs and push the changes to the Git repository.
 +
 ArgoCD pulls the changes from the Git repository and generates the policies on the hub cluster.