Merge pull request #49291 from amolnar-rh/TELCODOCS-676

stevsmit · web-flow · commit 4bc721573fb3 · 2022-09-28T16:16:40.000-04:00
TELCODOCS-676: Update variables in RAN docs
diff --git a/modules/cnf-topology-aware-lifecycle-manager-installation-cli.adoc b/modules/cnf-topology-aware-lifecycle-manager-installation-cli.adoc
@@ -51,10 +51,10 @@ $ oc get csv -n openshift-operators
 ----
 +
 .Example output
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-NAME                                                      DISPLAY                            VERSION               REPLACES   PHASE
-topology-aware-lifecycle-manager.4.10.0-202206301927      Topology Aware Lifecycle Manager   4.10.0-202206301927              Succeeded
+NAME                                                   DISPLAY                            VERSION               REPLACES                           PHASE
+topology-aware-lifecycle-manager.{product-version}.x   Topology Aware Lifecycle Manager   {product-version}.x                                      Succeeded
 ----
 
 . Verify that the {cgu-operator} is up and running:
@@ -69,4 +69,4 @@ $ oc get deploy -n openshift-operators
 ----
 NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
 openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s
-----
+----
diff --git a/modules/cnf-topology-aware-lifecycle-manager-operator-update.adoc b/modules/cnf-topology-aware-lifecycle-manager-operator-update.adoc
@@ -22,7 +22,7 @@ You can perform an Operator update with the {cgu-operator}.
 . Update the `PolicyGenTemplate` CR for the Operator update.
 .. Update the `du-upgrade` `PolicyGenTemplate` CR with the following additional contents in the `du-upgrade.yaml` file:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: ran.openshift.io/v1
 kind: PolicyGenTemplate
@@ -42,7 +42,7 @@ spec:
         name: redhat-operators
       spec:
         displayName: Red Hat Operators Catalog
-        image: registry.example.com:5000/olm/redhat-operators:v4.10 <1>
+        image: registry.example.com:5000/olm/redhat-operators:v{product-version} <1>
         updateStrategy: <2>
           registryPoll:
             interval: 1h
@@ -96,6 +96,11 @@ spec:
 ----
 
 .. 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.
+====
 
 .. Push the `PolicyGenTemplate` CRs updates to the ZTP Git repository.
 +
@@ -165,7 +170,7 @@ spec:
   enable: false
 ----
 <1> The policy is needed by the image pre-caching feature to retrieve the operator images from the catalog source.
-<2> The policy contains Operator subscriptions. If you have upgraded ZTP from 4.9 to 4.10 by following "Upgrade ZTP from 4.9 to 4.10", all Operator subscriptions are grouped into the `common-subscriptions-policy` policy.
+<2> The policy contains Operator subscriptions. If you have followed the structure and content of the reference `PolicyGenTemplates`, all Operator subscriptions are grouped into the `common-subscriptions-policy` policy.
 +
 [NOTE]
 ====
diff --git a/modules/cnf-topology-aware-lifecycle-manager-platform-update.adoc b/modules/cnf-topology-aware-lifecycle-manager-platform-update.adoc
@@ -22,9 +22,9 @@ You can perform a platform update with the {cgu-operator}.
 . Create a `PolicyGenTemplate` CR for the platform update:
 .. Save the following contents of the `PolicyGenTemplate` CR in the `du-upgrade.yaml` file.
 +
-.Example of `PolicyGenTemplate` for platform update 
+.Example of `PolicyGenTemplate` for platform update
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: ran.openshift.io/v1
 kind: PolicyGenTemplate
@@ -36,7 +36,7 @@ spec:
     group-du-sno: ""
   mcp: "master"
   remediationAction: inform
-  sourceFiles: 
+  sourceFiles:
     - fileName: ImageSignature.yaml <1>
       policyName: "platform-upgrade-prep"
       binaryData:
@@ -60,20 +60,20 @@ spec:
         annotations:
           ran.openshift.io/ztp-deploy-wave: "1"
       spec:
-        channel: "stable-4.10"
-        upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.10
+        channel: "stable-{product-version}"
+        upstream: http://upgrade.example.com/images/upgrade-graph_stable-{product-version}
     - fileName: ClusterVersion.yaml <5>
       policyName: "platform-upgrade"
       metadata:
         name: version
       spec:
-        channel: "stable-4.10"
-        upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.10
+        channel: "stable-{product-version}"
+        upstream: http://upgrade.example.com/images/upgrade-graph_stable-{product-version}
         desiredUpdate:
-          version: 4.10.4
+          version: {product-version}.4
       status:
         history:
-          - version: 4.10.4
+          - version: {product-version}.4
             state: "Completed"
 ----
 <1> The `ConfigMap` CR contains the signature of the desired release image to update to.
diff --git a/modules/cnf-topology-aware-lifecycle-manager-preparing-for-updates.adoc b/modules/cnf-topology-aware-lifecycle-manager-preparing-for-updates.adoc
@@ -11,7 +11,7 @@ If you have deployed spoke clusters with distributed unit (DU) profiles using th
 [id="talo-platform-prepare-for-update_{context}"]
 == Preparing for the updates
 
-If both the hub and the spoke clusters are running {product-title} 4.9, you must update ZTP from version 4.9 to 4.10. If {product-title} 4.10 is used, you can set up the environment.
+This procedure makes use of the Topology Aware Lifecycle Manager (TALM) which requires the 4.10 version or later of the ZTP container for compatibility.
 
 [id="talo-platform-prepare-for-update-env-setup_{context}"]
 == Setting up the environment
@@ -97,9 +97,9 @@ For more information about how to set up the graph on the hub cluster, see link:
 
 .. Make a local copy of the upstream graph. Host the update graph on an `http` or `https` server in the disconnected environment that has access to the spoke cluster. To download the update graph, use the following command:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.10 -o ~/upgrade-graph_stable-4.10
+$ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-{product-version} -o ~/upgrade-graph_stable-{product-version}
 ----
 
 * For Operator updates, you must perform the following task:
diff --git a/modules/nw-rfhe-installing-operator-cli.adoc b/modules/nw-rfhe-installing-operator-cli.adoc
@@ -96,8 +96,8 @@ $ oc get csv -n openshift-bare-metal-events -o custom-columns=Name:.metadata.nam
 ----
 
 .Example output
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-Name                                                    Phase
-bare-metal-event-relay.4.10.0-202206301927              Succeeded
+Name                                                          Phase
+bare-metal-event-relay.{product-version}.0-xxxxxxxxxxxx            Succeeded
 ----
diff --git a/modules/ztp-adding-new-content-to-gitops-ztp.adoc b/modules/ztp-adding-new-content-to-gitops-ztp.adoc
@@ -24,33 +24,33 @@ ztp-update/
 
 . Add the following content to the `ztp-update.in` Containerfile:
 +
-[source,text]
+[source,text,subs="attributes+"]
 ----
-FROM registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10
+FROM registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version}
 
 ADD example-cr2.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/
 ADD example-cr1.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/
 ----
 
 . Open a terminal at the `ztp-update/` folder and rebuild the container:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ podman build -t ztp-site-generate-rhel8-custom:v4.10-custom-1
+$ podman build -t ztp-site-generate-rhel8-custom:v{product-version}-custom-1
 ----
 
 . Push the built container image to your disconnected registry, for example:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ podman push localhost/ztp-site-generate-rhel8-custom:v4.10-custom-1 registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.10-custom-1
+$ podman push localhost/ztp-site-generate-rhel8-custom:v{product-version}-custom-1 registry.example.com:5000/ztp-site-generate-rhel8-custom:v{product-version}-custom-1
 ----
 
 . Patch the Argo CD instance on the hub cluster to point to the newly built container image:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ oc patch -n openshift-gitops argocd openshift-gitops --type=json -p '[{"op": "replace", "path":"/spec/repo/initContainers/0/image", "value": "registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.10-custom-1"} ]'
+$ oc patch -n openshift-gitops argocd openshift-gitops --type=json -p '[{"op": "replace", "path":"/spec/repo/initContainers/0/image", "value": "registry.example.com:5000/ztp-site-generate-rhel8-custom:v{product-version}-custom-1"} ]'
 ----
 +
 When the Argo CD instance is patched, the `openshift-gitops-repo-server` pod automatically restarts.
diff --git a/modules/ztp-deploying-a-site.adoc b/modules/ztp-deploying-a-site.adoc
@@ -73,7 +73,7 @@ The folder includes example files for single node, three-node, and standard clus
 
 .. Change the cluster and host details in the example file to match the type of cluster you want. The following file is a composite of the three files that explains the configuration of each cluster type:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
 ---
@@ -86,7 +86,7 @@ spec:
   baseDomain: "example.com"
   pullSecretRef:
     name: "assisted-deployment-pull-secret"
-  clusterImageSetNameRef: "openshift-4.10" <1>
+  clusterImageSetNameRef: "openshift-{product-version}" <1>
   sshPublicKey: "ssh-rsa AAAA..."
   clusters:
   - clusterName: "example-sno"
diff --git a/modules/ztp-manually-install-a-single-managed-cluster.adoc b/modules/ztp-manually-install-a-single-managed-cluster.adoc
@@ -51,22 +51,20 @@ provisioner_cluster_registry }}/ocp4:{{ mirror_version_spoke_release }}
 
 * You mirrored the ISO and `rootfs` used to generate the spoke cluster ISO to an HTTP server and configured the settings to pull images from there.
 +
-The images must match the version of the `ClusterImageSet`. To deploy a 4.9.0 version, the `rootfs` and
-ISO must be set at 4.9.0.
-
+The images must match the version of the `ClusterImageSet`. For example, to deploy a {product-version}.0 version, the `rootfs` and ISO must be set to `{product-version}.0`.
 
 .Procedure
 
 . Create a `ClusterImageSet` for each specific cluster version that needs to be deployed. A `ClusterImageSet` has the following format:
 +
-[source,yaml]
+[source,yaml,subs="attributes+"]
 ----
 apiVersion: hive.openshift.io/v1
 kind: ClusterImageSet
 metadata:
-  name: openshift-4.9.0-rc.0 <1>
+  name: openshift-{product-version}.0 <1>
 spec:
-   releaseImage: quay.io/openshift-release-dev/ocp-release:4.9.0-x86_64 <2>
+   releaseImage: quay.io/openshift-release-dev/ocp-release:{product-version}.0-x86_64 <2>
 ----
 <1> The descriptive version that you want to deploy.
 <2> Specifies the `releaseImage` to deploy and determines the OS Image version. The discovery ISO is based on an OS image version as the `releaseImage`, or latest if the exact version is unavailable.
diff --git a/modules/ztp-preparing-for-the-gitops-ztp-upgrade.adoc b/modules/ztp-preparing-for-the-gitops-ztp-upgrade.adoc
@@ -19,9 +19,9 @@ Use the following procedure to prepare your site for the GitOps zero touch provi
 $ mkdir -p ./out
 ----
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10 extract /home/ztp --tar | tar x -C ./out
+$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar | tar x -C ./out
 ----
 +
 The `/out` directory contains the following subdirectories:
diff --git a/modules/ztp-preparing-the-hub-cluster-for-ztp.adoc b/modules/ztp-preparing-the-hub-cluster-for-ztp.adoc
@@ -10,9 +10,9 @@ You can configure your hub cluster with a set of ArgoCD applications that genera
 
 .Prerequisites
 
-* Openshift Cluster 4.8 or 4.9 as the hub cluster
-* {rh-rhacm-first} Operator 2.3 or 2.4 installed on the hub cluster
-* Red Hat OpenShift GitOps Operator 1.3 on the hub cluster
+* Openshift Cluster 4.11 as the hub cluster
+* {rh-rhacm-first} Operator 2.5 installed on the hub cluster
+* Red Hat OpenShift GitOps Operator 1.5 on the hub cluster
 
 .Procedure
 
diff --git a/modules/ztp-preparing-the-ztp-git-repository.adoc b/modules/ztp-preparing-the-ztp-git-repository.adoc
@@ -14,19 +14,19 @@ Create a Git repository for hosting site configuration data. The zero touch prov
 
 . Export the `argocd` directory from the `ztp-site-generate` container image using the following commands:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10
+$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version}
 ----
 +
 [source,terminal]
 ----
 $ mkdir -p ./out
 ----
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10 extract /home/ztp --tar | tar x -C ./out
+$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar | tar x -C ./out
 ----
 
 . Check that the `out` directory contains the following subdirectories:
diff --git a/modules/ztp-required-changes-to-the-git-repository.adoc b/modules/ztp-required-changes-to-the-git-repository.adoc
@@ -6,7 +6,7 @@
 [id="ztp-required-changes-to-the-git-repository_{context}"]
 = Required changes to the Git repository
 
-When upgrading from an earlier release to {product-title} 4.10, additional requirements are placed on the contents of the Git repository. Existing content in the repository must be updated to reflect these changes.
+When upgrading the `ztp-site-generate` container from an earlier release to the 4.10 version, additional requirements are placed on the contents of the Git repository. Existing content in the repository must be updated to reflect these changes.
 
 * Changes to `PolicyGenTemplate` files:
 +
diff --git a/modules/ztp-roll-out-the-configuration-changes.adoc b/modules/ztp-roll-out-the-configuration-changes.adoc
@@ -6,6 +6,6 @@
 [id="ztp-roll-out-the-configuration-changes_{context}"]
 = Roll out the configuration changes
 
-If any configuration changes were included in the upgrade due to implementing recommended changes, the upgrade process results in a set of policy CRs on the hub cluster in the `Non-Compliant` state. As of the {product-title} 4.10 release, these policies are set to `inform` mode and are not pushed to the spoke clusters without an additional step by the user. This ensures that potentially disruptive changes to the clusters can be managed in terms of when the changes are made, for example, during a maintenance window, and how many clusters are updated concurrently.
+If any configuration changes were included in the upgrade due to implementing recommended changes, the upgrade process results in a set of policy CRs on the hub cluster in the `Non-Compliant` state. As of the {product-title} 4.10 version of the `ztp-site-generate` container, these policies are set to `inform` mode and are not pushed to the spoke clusters without an additional step by the user. This ensures that potentially disruptive changes to the clusters can be managed in terms of when the changes are made, for example, during a maintenance window, and how many clusters are updated concurrently.
 
-To roll out the changes, create one or more `ClusterGroupUpgrade` CRs as detailed in the {cgu-operator} documentation. The CR must contain the list of `Non-Compliant` policies that you want to push out to the spoke clusters as well as a list or selector of which clusters should be included in the update.
+To roll out the changes, create one or more `ClusterGroupUpgrade` CRs as detailed in the {cgu-operator} documentation. The CR must contain the list of `Non-Compliant` policies that you want to push out to the spoke clusters as well as a list or selector of which clusters should be included in the update.
diff --git a/modules/ztp-using-pgt-to-update-source-crs.adoc b/modules/ztp-using-pgt-to-update-source-crs.adoc
@@ -27,9 +27,9 @@ $ mkdir -p ./out
 
 .. Extract the source CRs:
 +
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
-$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10 extract /home/ztp --tar | tar x -C ./out
+$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar | tar x -C ./out
 ----
 
 . Review the baseline `PerformanceProfile` CR in `./out/source-crs/PerformanceProfile.yaml`:

Original file line number	Diff line number	Diff line change
`@@ -19,9 +19,9 @@ Use the following procedure to prepare your site for the GitOps zero touch provi`
`19`	`19`	`$ mkdir -p ./out`
`20`	`20`	`----`
`21`	`21`	`+`
`22`		`-[source,terminal]`
	`22`	`+[source,terminal,subs="attributes+"]`
`23`	`23`	`----`
`24`		`-$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10 extract /home/ztp --tar \| tar x -C ./out`
	`24`	`+$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar \| tar x -C ./out`
`25`	`25`	`----`
`26`	`26`	`+`
`27`	`27`	The `/out` directory contains the following subdirectories: