Merge pull request #43138 from sagidlow/OSDOCS-3172

sagidlow · web-flow · commit 4dff8282c51f · 2022-04-18T16:57:03.000-04:00
OSDOCS-3172: Changing terminology from upgrade to update
diff --git a/modules/understanding-upgrade-channels.adoc b/modules/understanding-upgrade-channels.adoc
@@ -16,7 +16,7 @@ Cluster administrators can configure the upgrade channel from the web console.
 
 The `candidate-{product-version}` channel contains candidate builds for a z-stream ({product-version}.z) and previous minor version releases. Release candidates contain all the features of the product but are not supported. Use release candidate versions to test feature acceptance and assist in qualifying the next version of {product-title}. A release candidate is any build that is available in the candidate channel, including ones that do not contain link:https://semver.org/spec/v2.0.0.html#spec-item-9[a pre-release version] such as `-rc` in their names. After a version is available in the candidate channel, it goes through more quality checks. If it meets the quality standard, it is promoted to the `fast-{product-version}` or `stable-{product-version}` channels. Because of this strategy, if a specific release is available in both the `candidate-{product-version}` channel and in the `fast-{product-version}` or `stable-{product-version}` channels, it is a Red Hat-supported version. The `candidate-{product-version}` channel can include release versions from which there are no recommended updates in any channel.
 
-You can use the `candidate-{product-version}` channel to upgrade from a previous minor version of {product-title}.
+You can use the `candidate-{product-version}` channel to update from a previous minor version of {product-title}.
 
 [NOTE]
 ====
diff --git a/modules/update-configuring-image-signature.adoc b/modules/update-configuring-image-signature.adoc
@@ -15,7 +15,7 @@ You must perform following steps each time that you update a cluster.
 
 .Procedure
 
-. Review the link:https://access.redhat.com/solutions/4583231[{product-title} upgrade paths] knowledge base article to determine a valid upgrade path for your cluster.
+. Review the link:https://access.redhat.com/solutions/4583231[{product-title} upgrade paths] knowledge base article to determine a valid update path for your cluster.
 
 . Add the version to the `OCP_RELEASE_NUMBER` environment variable:
 +
diff --git a/modules/update-mirror-repository.adoc b/modules/update-mirror-repository.adoc
@@ -6,11 +6,11 @@
 [id="update-mirror-repository_{context}"]
 = Mirroring the {product-title} image repository
 
-Before you upgrade a cluster on infrastructure that you provision in a restricted network, you must mirror the required container images into that environment. You can also use this procedure in unrestricted networks to ensure your clusters only use container images that have satisfied your organizational controls on external content.
+Before you update a cluster on infrastructure that you provision in a restricted network, you must mirror the required container images into that environment. You can also use this procedure in unrestricted networks to ensure your clusters only use container images that have satisfied your organizational controls on external content.
 
 .Procedure
 
-. Use the link:https://access.redhat.com/labs/ocpupgradegraph/update_channel[Red Hat {product-title} Upgrade Graph visualizer and update planner] to plan an upgrade from one version to another. The OpenShift Upgrade Graph provides channel graphs and a way to confirm that there is an update path between your current and intended cluster versions.
+. Use the link:https://access.redhat.com/labs/ocpupgradegraph/update_channel[Red Hat {product-title} Upgrade Graph visualizer and update planner] to plan an update from one version to another. The OpenShift Upgrade Graph provides channel graphs and a way to confirm that there is an update path between your current and intended cluster versions.
 
 . Set the required environment variables:
 .. Export the release version:
@@ -20,7 +20,7 @@ Before you upgrade a cluster on infrastructure that you provision in a restricte
 $ export OCP_RELEASE=<release_version>
 ----
 +
-For `<release_version>`, specify the tag that corresponds to the version of {product-title} to which you want to upgrade, such as `4.5.4`.
+For `<release_version>`, specify the tag that corresponds to the version of {product-title} to which you want to update, such as `4.5.4`.
 
 .. Export the local registry name and host port:
 +
diff --git a/modules/update-service-mirror-release.adoc b/modules/update-service-mirror-release.adoc
@@ -28,7 +28,7 @@ Complete the following steps on the mirror host:
 
 . Review the
 link:https://access.redhat.com/downloads/content/290/[{product-title} downloads page]
-to determine the version of {product-title} to which you want to upgrade and determine the corresponding tag on the link:https://quay.io/repository/openshift-release-dev/ocp-release?tab=tags[Repository Tags] page.
+to determine the version of {product-title} to which you want to update and determine the corresponding tag on the link:https://quay.io/repository/openshift-release-dev/ocp-release?tab=tags[Repository Tags] page.
 
 . Set the required environment variables:
 .. Export the release version:
diff --git a/modules/update-service-overview.adoc b/modules/update-service-overview.adoc
@@ -23,7 +23,7 @@ To allow the OpenShift Update Service to provide only compatible updates, a rele
 
 [IMPORTANT]
 ====
-The OpenShift Update Service displays all recommended updates for your current cluster.  If an upgrade path is not recommended by the OpenShift Update Service, it might be because of a known issue with the update or the target release.
+The OpenShift Update Service displays all recommended updates for your current cluster.  If an update path is not recommended by the OpenShift Update Service, it might be because of a known issue with the update or the target release.
 ====
 
 ////
@@ -34,10 +34,10 @@ Two controllers run during continuous update mode. The first controller continuo
 
 [IMPORTANT]
 ====
-Only upgrading to a newer version is supported. Reverting or rolling back your cluster to a previous version is not supported. If your upgrade fails, contact Red Hat support.
+Only upgrading to a newer version is supported. Reverting or rolling back your cluster to a previous version is not supported. If your update fails, contact Red Hat support.
 ====
 
-During the upgrade process, the Machine Config Operator (MCO) applies the new configuration to your cluster machines. The MCO cordons the number of nodes as specified by the `maxUnavailable` field on the machine configuration pool and marks them as unavailable. By default, this value is set to `1`. The MCO then applies the new configuration and reboots the machine.
+During the update process, the Machine Config Operator (MCO) applies the new configuration to your cluster machines. The MCO cordons the number of nodes as specified by the `maxUnavailable` field on the machine configuration pool and marks them as unavailable. By default, this value is set to `1`. The MCO then applies the new configuration and reboots the machine.
 
 If you use {op-system-base-full} machines as workers, the MCO does not update the kubelet because you must update the OpenShift API on the machines first.
 
diff --git a/modules/update-upgrading-web.adoc b/modules/update-upgrading-web.adoc
@@ -34,7 +34,7 @@ For production clusters, you must subscribe to a `stable-\*` or `fast-*` channel
 ifdef::openshift-origin[]
 such as `stable-4`.
 endif::openshift-origin[]
-** If the *Update status* is not *Updates available*, you cannot upgrade your cluster.
+** If the *Update status* is not *Updates available*, you cannot update your cluster.
 ** *Select channel* indicates the cluster version that your cluster is running or is updating to.
 
 . Select a version to update to and click *Save*.
@@ -44,7 +44,7 @@ The Input channel
 +
 [NOTE]
 ====
-If you are upgrading your cluster to the next minor version, like version 4.y to 4.(y+1), it is recommended to confirm your nodes are upgraded before deploying workloads that rely on a new feature. Any pools with worker nodes that are not yet updated are displayed on the *Cluster Settings* page.
+If you are upgrading your cluster to the next minor version, like version 4.y to 4.(y+1), it is recommended to confirm your nodes are updated before deploying workloads that rely on a new feature. Any pools with worker nodes that are not yet updated are displayed on the *Cluster Settings* page.
 ====
 
 . After the update completes and the Cluster Version Operator refreshes the available updates, check if more updates are available in your current channel.
diff --git a/modules/update-vsphere-virtual-hardware-on-compute-nodes.adoc b/modules/update-vsphere-virtual-hardware-on-compute-nodes.adoc
@@ -6,11 +6,11 @@
 [id="update-vsphere-virtual-hardware-on-compute-nodes_{context}"]
 = Updating the virtual hardware for compute nodes on vSphere
 
-To reduce the risk of downtime, it is recommended that compute nodes be upgraded serially.
+To reduce the risk of downtime, it is recommended that compute nodes be updated serially.
 
 [NOTE]
 ====
-Multiple compute nodes can be upgraded in parallel given workloads are tolerant of having multiple nodes in a `NotReady` state. It is the responsibility of the administrator to ensure that the required compute nodes are available.
+Multiple compute nodes can be updated in parallel given workloads are tolerant of having multiple nodes in a `NotReady` state. It is the responsibility of the administrator to ensure that the required compute nodes are available.
 ====
 
 .Prerequisites
@@ -56,7 +56,7 @@ See the "Understanding how to evacuate pods on nodes" section for other options
 
 . Shut down the virtual machine (VM) associated with the compute node. Do this in the vSphere client by right-clicking the VM and selecting *Power* -> *Shut Down Guest OS*. Do not shut down the VM using *Power Off* because it might not shut down safely.
 
-. Upgrade the VM in the vSphere client. Follow link:https://kb.vmware.com/s/article/1010675[Upgrading a virtual machine to the latest hardware version] in the VMware documentation for more information.
+. Update the VM in the vSphere client. Follow link:https://kb.vmware.com/s/article/1010675[Upgrading a virtual machine to the latest hardware version] in the VMware documentation for more information.
 
 . Power on the VM associated with the compute node. Do this in the vSphere client by right-clicking the VM and selecting *Power On*.
 
diff --git a/modules/update-vsphere-virtual-hardware-on-control-plane-nodes.adoc b/modules/update-vsphere-virtual-hardware-on-control-plane-nodes.adoc
@@ -6,7 +6,7 @@
 [id="update-vsphere-virtual-hardware-on-control-plane-nodes_{context}"]
 = Updating the virtual hardware for control plane nodes on vSphere
 
-To reduce the risk of downtime, it is recommended that control plane nodes be upgraded serially. This ensures that the Kubernetes API remains available and etcd retains quorum.
+To reduce the risk of downtime, it is recommended that control plane nodes be updated serially. This ensures that the Kubernetes API remains available and etcd retains quorum.
 
 .Prerequisites
 
@@ -42,7 +42,7 @@ $ oc adm cordon <control_plane_node>
 
 . Shut down the virtual machine (VM) associated with the control plane node. Do this in the vSphere client by right-clicking the VM and selecting *Power* -> *Shut Down Guest OS*. Do not shut down the VM using *Power Off* because it might not shut down safely.
 
-. Upgrade the VM in the vSphere client. Follow link:https://kb.vmware.com/s/article/1010675[Upgrading a virtual machine to the latest hardware version] in the VMware documentation for more information.
+. Update the VM in the vSphere client. Follow link:https://kb.vmware.com/s/article/1010675[Upgrading a virtual machine to the latest hardware version] in the VMware documentation for more information.
 
 . Power on the VM associated with the control plane node. Do this in the vSphere client by right-clicking the VM and selecting *Power On*.
 
diff --git a/modules/updating-clear.adoc b/modules/updating-clear.adoc
@@ -6,9 +6,9 @@
 = Recovering when an update fails before it is applied
 
 If an update fails before it is applied, such as when the version that you
-specify cannot be found, you can cancel the upgrade:
+specify cannot be found, you can cancel the update:
 
 [source,terminal]
 ----
 $ oc adm upgrade clear
-----
+----
diff --git a/updating/installing-update-service.adoc b/updating/installing-update-service.adoc
@@ -13,7 +13,7 @@ toc::[]
 
 For clusters with internet accessibility, Red Hat provides over-the-air updates through an {product-title} update service as a hosted service located behind public APIs. However, clusters in a restricted network have no way to access public APIs for update information.
 
-To provide a similar upgrade experience in a restricted network, you can install and configure the OpenShift Update Service locally so that it is available within a disconnected environment.
+To provide a similar update experience in a restricted network, you can install and configure the OpenShift Update Service locally so that it is available within a disconnected environment.
 
 The following sections describe how to provide over-the-air updates for your disconnected cluster and its underlying operating system.
 
@@ -86,7 +86,7 @@ include::modules/update-service-configure-cvo.adoc[leveloffset=+2]
 
 [NOTE]
 ====
-See xref:../networking/enable-cluster-wide-proxy.adoc#nw-proxy-configure-object[Enabling the cluster-wide proxy] to configure the CA to trust the update server. 
+See xref:../networking/enable-cluster-wide-proxy.adoc#nw-proxy-configure-object[Enabling the cluster-wide proxy] to configure the CA to trust the update server.
 ====
 
 [id="update-service-delete-service"]
diff --git a/updating/understanding-openshift-updates.adoc b/updating/understanding-openshift-updates.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 With {product-title} 4, you can update a {product-title} cluster with a single operation by using the web console or the OpenShift CLI (`oc`). Platform administrators are automatically notified when an update is available for their cluster.
 
-The OpenShift Update Service (OSUS) builds a graph of upgrade possibilities based on release images in the registry.
+The OpenShift Update Service (OSUS) builds a graph of update possibilities based on release images in the registry.
 The graph is based on recommended, tested update paths from a specific version. {product-title} clusters connect to the Red Hat Hybrid Cloud servers and identify which clusters the user is running, along with the version information. OSUS responds with information about known update targets. Either a cluster administrator or an automatic update controller edits the custom resource (CR) of the Cluster Version Operator (CVO) with the new version to update to.
 After the CVO receives the update image from the registry, the CVO then applies the changes.
 
diff --git a/updating/understanding-upgrade-channels-release.adoc b/updating/understanding-upgrade-channels-release.adoc
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-In {product-title} 4.1, Red Hat introduced the concept of channels for recommending the appropriate release versions for cluster upgrades. By controlling the pace of upgrades, these upgrade channels allow you to choose an upgrade strategy. Upgrade channels are tied to a minor version of {product-title}. For instance, {product-title} 4.9 upgrade channels recommend upgrades to 4.9 and upgrades within 4.9. They also recommend upgrades within 4.8 and from 4.8 to 4.9, to allow clusters on 4.8 to eventually upgrade to 4.9. They do not recommend upgrades to 4.10 or later releases. This strategy ensures that administrators explicitly decide to upgrade to the next minor version of {product-title}.
+In {product-title} 4.1, Red Hat introduced the concept of channels for recommending the appropriate release versions for cluster updates. By controlling the pace of updates, these upgrade channels allow you to choose an update strategy. Upgrade channels are tied to a minor version of {product-title}. For instance, {product-title} 4.9 upgrade channels recommend updates to 4.9 and updates within 4.9. They also recommend updates within 4.8 and from 4.8 to 4.9, to allow clusters on 4.8 to eventually update to 4.9. They do not recommend updates to 4.10 or later releases. This strategy ensures that administrators explicitly decide to update to the next minor version of {product-title}.
 
 Upgrade channels control only release selection and do not impact the version of the cluster that you install; the `openshift-install` binary file for a specific version of {product-title} always installs that version.
 
@@ -18,11 +18,11 @@ ifndef::openshift-origin[]
 * `stable-{product-version}`
 * `eus-4.y` (only when running an even-numbered 4.y cluster release, like 4.10)
 
-If you do not want the Cluster Version Operator to fetch available updates from the upgrade recommendation service, you can use the `oc adm upgrade channel` command in the OpenShift CLI to configure an empty channel. This configuration can be helpful if, for example, a cluster has restricted network access and there is no local, reachable upgrade recommendation service.
+If you do not want the Cluster Version Operator to fetch available updates from the update recommendation service, you can use the `oc adm upgrade channel` command in the OpenShift CLI to configure an empty channel. This configuration can be helpful if, for example, a cluster has restricted network access and there is no local, reachable update recommendation service.
 
 [WARNING]
 ====
-Red Hat recommends upgrading to versions suggested by Openshift Update Service only. For minor version upgrade, versions must be contiguous. Red Hat does not test upgrades to noncontiguous versions and cannot guarantee compatibility with earlier versions.
+Red Hat recommends upgrading to versions suggested by Openshift Update Service only. For a minor version update, versions must be contiguous. Red Hat does not test updates to noncontiguous versions and cannot guarantee compatibility with earlier versions.
 ====
 
 endif::openshift-origin[]
diff --git a/updating/updating-cluster-cli.adoc b/updating/updating-cluster-cli.adoc
diff --git a/updating/updating-cluster-prepare.adoc b/updating/updating-cluster-prepare.adoc
diff --git a/updating/updating-cluster-rhel-compute.adoc b/updating/updating-cluster-rhel-compute.adoc
diff --git a/updating/updating-cluster-within-minor.adoc b/updating/updating-cluster-within-minor.adoc
diff --git a/updating/updating-cluster.adoc b/updating/updating-cluster.adoc
diff --git a/updating/updating-restricted-network-cluster.adoc b/updating/updating-restricted-network-cluster.adoc

Original file line number	Diff line number	Diff line change
`@@ -15,7 +15,7 @@ You must perform following steps each time that you update a cluster.`
`15`	`15`
`16`	`16`	`.Procedure`
`17`	`17`
`18`		`-. Review the link:https://access.redhat.com/solutions/4583231[{product-title} upgrade paths] knowledge base article to determine a valid upgrade path for your cluster.`
	`18`	`+. Review the link:https://access.redhat.com/solutions/4583231[{product-title} upgrade paths] knowledge base article to determine a valid update path for your cluster.`
`19`	`19`
`20`	`20`	. Add the version to the `OCP_RELEASE_NUMBER` environment variable:
`21`	`21`	`+`