Merge pull request #81839 from obrown1205/OSDOCS-11838-2

jab-rh · web-flow · commit 82dd0eea1d0b · 2024-09-23T12:12:51.000-04:00
OSDOCS-11838: Renaming EUS-to-EUS updates
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -732,8 +732,8 @@ Topics:
     File: updating-cluster-cli
   - Name: Updating a cluster using the web console
     File: updating-cluster-web-console
-  - Name: Performing an EUS-to-EUS update
-    File: eus-eus-update
+  - Name: Performing a Control Plane Only update
+    File: control-plane-only-update
     Distros: openshift-enterprise
   - Name: Performing a canary rollout update
     File: update-using-custom-machine-config-pools
diff --git a/disconnected/updating/disconnected-update-osus.adoc b/disconnected/updating/disconnected-update-osus.adoc
@@ -141,6 +141,6 @@ After you configure your cluster to use the installed OpenShift Update Service a
 
 ** xref:../../updating/updating_a_cluster/updating-cluster-web-console.adoc#updating-cluster-web-console[Updating a cluster using the web console]
 ** xref:../../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI]
-** xref:../../updating/updating_a_cluster/eus-eus-update.adoc#eus-eus-update[Performing an EUS-to-EUS update]
+** xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update]
 ** xref:../../updating/updating_a_cluster/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools[Performing a canary rollout update]
 ** xref:../../updating/updating_a_cluster/updating-cluster-rhel-compute.adoc#updating-cluster-rhel-compute[Updating a cluster that includes RHEL compute machines]
diff --git a/modules/persistent-storage-csi-migration-vsphere.adoc b/modules/persistent-storage-csi-migration-vsphere.adoc
@@ -47,5 +47,5 @@ If you do *not* update to vSphere 7.0 Update 3L or 8.0 Update 2 and use an admin
 ====
 
 ifndef::openshift-origin[]
-Updating from {product-title} 4.12 to 4.14 is an Extended Update Support (EUS)-to-EUS update. To understand the ramifications for this type of update and how to perform it, see the _EUS-to-EUS update_ link in the _Additional resources_ section below.
+Updating from {product-title} 4.12 to 4.14 is an Extended Update Support (EUS)-to-EUS update. To understand the ramifications for this type of update and how to perform it, see the _Control Plane Only update_ link in the _Additional resources_ section below.
 endif::openshift-origin[]
diff --git a/modules/understanding-update-channels.adoc b/modules/understanding-update-channels.adoc
@@ -26,7 +26,7 @@ Newly installed clusters default to using stable channels.
 [id="eus-4y-channel_{context}"]
 == eus-4.y channel
 
-In addition to the stable channel, all even-numbered minor versions of {product-title} offer link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[Extended Update Support] (EUS). Releases promoted to the stable channel are also simultaneously promoted to the EUS channels. The primary purpose of the EUS channels is to serve as a convenience for clusters performing an EUS-to-EUS update.
+In addition to the stable channel, all even-numbered minor versions of {product-title} offer link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[Extended Update Support] (EUS). Releases promoted to the stable channel are also simultaneously promoted to the EUS channels. The primary purpose of the EUS channels is to serve as a convenience for clusters performing a Control Plane Only update.
 
 [NOTE]
 ====
@@ -90,7 +90,7 @@ First, select the minor version you want for your cluster update. Selecting a ch
 
 [NOTE]
 ====
-Due to the complexity involved in planning updates between versions many minors apart, channels that assist in planning updates beyond a single EUS-to-EUS update are not offered.
+Due to the complexity involved in planning updates between versions many minors apart, channels that assist in planning updates beyond a single Control Plane Only update are not offered.
 ====
 
 Second, you should choose your desired rollout strategy. You may choose to update as soon as Red Hat declares a release GA by selecting from fast channels or you may want to wait for Red Hat to promote releases to the stable channel. Update recommendations offered in the `fast-{product-version}` and `stable-{product-version}` are both fully supported and benefit equally from ongoing data analysis. The promotion delay before promoting a release to the stable channel represents the only difference between the two channels. Updates to the latest z-streams are generally promoted to the stable channel within a week or two, however the delay when initially rolling out updates to the latest minor is much longer, generally 45-90 days. Please consider the promotion delay when choosing your desired channel, as waiting for promotion to the stable channel may affect your scheduling plans.
diff --git a/modules/update-availability-faq.adoc b/modules/update-availability-faq.adoc
@@ -23,7 +23,7 @@ For the latest z-stream releases, this delay may generally be a week or two. How
 ====
 
 * Releases promoted to the `stable` channel are simultaneously promoted to the `eus` channel.
-The primary purpose of the `eus` channel is to serve as a convenience for clusters performing an EUS-to-EUS update.
+The primary purpose of the `eus` channel is to serve as a convenience for clusters performing a Control Plane Only update.
 
 [id="channel-safety_{context}"]
 *Is a release on the `stable` channel safer or more supported than a release on the `fast` channel?*
diff --git a/modules/update-common-terms.adoc b/modules/update-common-terms.adoc
@@ -16,12 +16,4 @@ OpenShift Update Service:: The _OpenShift Update Service_ (OSUS) provides over-t
 
 Channels:: _Channels_ declare an update strategy tied to minor versions of {product-title}. The OSUS uses this configured strategy to recommend update edges consistent with that strategy.
 
-Recommended update edge:: A _recommended update edge_ is a recommended update between {product-title} releases.  Whether a given update is recommended can depend on the cluster's configured channel, current version, known bugs, and other information. OSUS communicates the recommended edges to the CVO, which runs in every cluster.
-
-ifndef::openshift-origin[]
-
-Extended Update Support:: All post-4.7 even-numbered minor releases are labeled as _Extended Update Support_ (EUS) releases. These releases introduce a verified update path between EUS releases, permitting customers to streamline updates of worker nodes and formulate update strategies of EUS-to-EUS {product-title} releases that result in fewer reboots of worker nodes.
-+
-For more information, see link:https://access.redhat.com/support/policy/updates/openshift-eus[Red Hat OpenShift Extended Update Support (EUS) Overview].
-
-endif::openshift-origin[]
+Recommended update edge:: A _recommended update edge_ is a recommended update between {product-title} releases. Whether a given update is recommended can depend on the cluster's configured channel, current version, known bugs, and other information. OSUS communicates the recommended edges to the CVO, which runs in every cluster.
diff --git a/modules/update-upgrading-cli.adoc b/modules/update-upgrading-cli.adoc
@@ -69,7 +69,7 @@ endif::openshift-origin[]
 * If there are no recommended updates, updates that have known issues might still be available.
 See _Updating along a conditional update path_ for more information.
 ifndef::openshift-origin[]
-* For details and information on how to perform an `EUS-to-EUS` channel update, please refer to the _Preparing to perform an EUS-to-EUS upgrade_ page, listed in the Additional resources section.
+* For details and information on how to perform a `Control Plane Only` update, please refer to the _Preparing to perform a Control Plane Only update_ page, listed in the Additional resources section.
 endif::openshift-origin[]
 ====
 ifndef::openshift-origin[]
diff --git a/modules/updating-control-plane-only-layered-products.adoc b/modules/updating-control-plane-only-layered-products.adoc
@@ -1,12 +1,12 @@
 // Module included in the following assemblies:
 //
-// * updating/updating_a_cluster/eus-eus-update.adoc
+// * updating/updating_a_cluster/control-plane-only-update.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="updating-eus-to-eus-olm-operators_{context}"]
-= EUS-to-EUS update for layered products and Operators installed through Operator Lifecycle Manager
+[id="updating-control-plane-only-olm-operators_{context}"]
+= Control Plane Only updates for layered products and Operators installed through Operator Lifecycle Manager
 
-In addition to the EUS-to-EUS update steps mentioned for the web console and CLI, there are additional steps to consider when performing EUS-to-EUS updates for clusters with the following:
+In addition to the Control Plane Only update steps mentioned for the web console and CLI, there are additional steps to consider when performing Control Plane Only updates for clusters with the following:
 
 * Layered products
 * Operators installed through Operator Lifecycle Manager (OLM)
@@ -15,13 +15,13 @@ In addition to the EUS-to-EUS update steps mentioned for the web console and CLI
 
 Layered products refer to products that are made of multiple underlying products that are intended to be used together and cannot be broken into individual subscriptions. For examples of layered {product-title} products, see link:https://access.redhat.com/support/policy/updates/openshift/#layered[Layered Offering On OpenShift].
 
-As you perform an EUS-to-EUS update for the clusters of layered products and those of Operators that have been installed through OLM, you must complete the following:
+As you perform a Control Plane Only update for the clusters of layered products and those of Operators that have been installed through OLM, you must complete the following:
 
 . You have updated all Operators previously installed through Operator Lifecycle Manager (OLM) to a version that is compatible with your target release. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See "Updating installed Operators" in the "Additional resources" section for more information on how to check compatibility and, if necessary, update the installed Operators.
 
 . Confirm the cluster version compatibility between the current and intended Operator versions. You can verify which versions your OLM Operators are compatible with by using the link:https://access.redhat.com/labs/ocpouic/?operator=logging&&ocp_versions=4.10,4.11,4.12[Red{nbsp}Hat {product-title} Operator Update Information Checker].
 
-As an example, here are the steps to perform an EUS-to-EUS update from <4.y> to <4.y+2> for OpenShift Data Foundation (ODF). This can be done through the CLI or web console. For information on how to update clusters through your desired interface, see _EUS-to-EUS update using the web console_ and "EUS-to-EUS update using the CLI" in "Additional resources".
+As an example, here are the steps to perform a Control Plane Only update from <4.y> to <4.y+2> for '{rh-storage}'. This can be done through the CLI or web console. For information about how to update clusters through your desired interface, see _Control Plane Only update using the web console_ and "Control Plane Only update using the CLI" in "Additional resources".
 
 .Example workflow
 . Pause the worker machine pools.
diff --git a/modules/updating-control-plane-only-update-cli.adoc b/modules/updating-control-plane-only-update-cli.adoc
@@ -1,10 +1,10 @@
 // Module included in the following assemblies:
 //
-// * updating/updating_a_cluster/eus-eus-update.adoc
+// * updating/updating_a_cluster/control-plane-only-update.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="updating-eus-to-eus-upgrade-cli_{context}"]
-= EUS-to-EUS update using the CLI
+[id="updating-control-plane-only-update-cli_{context}"]
+= Control Plane Only update using the CLI
 
 .Prerequisites
 
diff --git a/modules/updating-control-plane-only-update-console.adoc b/modules/updating-control-plane-only-update-console.adoc
@@ -1,10 +1,10 @@
 // Module included in the following assemblies:
 //
-// * updating/updating_a_cluster/eus-eus-update.adoc.adoc
+// * updating/updating_a_cluster/control-plane-only-update.adoc.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="updating-eus-to-eus-upgrade-console_{context}"]
-= EUS-to-EUS update using the web console
+[id="updating-control-plane-only-update-console_{context}"]
+= Control Plane Only update using the web console
 
 .Prerequisites
 
diff --git a/modules/updating-control-plane-only-update.adoc b/modules/updating-control-plane-only-update.adoc
@@ -0,0 +1,23 @@
+// Module included in the following assemblies:
+//
+// * updating/updating_a_cluster/control-plane-only-update.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="updating-control-plane-only-update_{context}"]
+= Performing a Control Plane Only update
+
+The following procedure pauses all non-`master` machine config pools and performs updates from {product-title} <4.y> to <4.y+1> to <4.y+2>, then unpauses the machine config pools.
+Following this procedure reduces the total update duration and the number of times worker nodes are restarted.
+
+.Prerequisites
+
+* Review the release notes for {product-title} <4.y+1> and <4.y+2>.
+* Review the release notes and product lifecycles for any layered products and Operator Lifecycle Manager (OLM) Operators. Some products and OLM Operators might require updates either before or during a Control Plane Only update.
+* Ensure that you are familiar with version-specific prerequisites, such as the removal of deprecated APIs, that are required before updating from {product-title} <4.y+1> to <4.y+2>.
+* If your cluster uses in-tree vSphere volumes, update vSphere to version 7.0u3L+ or 8.0u2+.
++
+[IMPORTANT]
+====
+If you do not update vSphere to 7.0u3L+ or 8.0u2+ before initiating an {product-title} update, known issues might occur with your cluster after the update.
+For more information, see link:https://access.redhat.com/node/7011683[Known Issues with OpenShift 4.12 to 4.13 or 4.13 to 4.14 vSphere CSI Storage Migration].
+====
diff --git a/modules/updating-eus-to-eus-upgrade.adoc b/modules/updating-eus-to-eus-upgrade.adoc
diff --git a/modules/virt-about-control-plane-only-updates.adoc b/modules/virt-about-control-plane-only-updates.adoc
@@ -3,8 +3,8 @@
 // * virt/updating/upgrading-virt.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="virt-about-eus-updates_{context}"]
-= About EUS-to-EUS updates
+[id="virt-about-control-plane-only-updates_{context}"]
+= About Control Plane Only updates
 
 Every even-numbered minor version of {product-title}, including 4.10 and 4.12, is an Extended Update Support (EUS) version. However, because Kubernetes design mandates serial minor version updates, you cannot directly update from one EUS version to the next.
 
@@ -15,9 +15,9 @@ When the {product-title} update succeeds, the corresponding update for {VirtProd
 [id="preparing-to-update_{context}"]
 == Preparing to update
 
-Before beginning an EUS-to-EUS update, you must:
+Before beginning a Control Plane Only update, you must:
 
-* Pause worker nodes' machine config pools before you start an EUS-to-EUS update so that the workers are not rebooted twice.
+* Pause worker nodes' machine config pools before you start a Control Plane Only update so that the workers are not rebooted twice.
 
 * Disable automatic workload updates before you begin the update process. This is to prevent {VirtProductName} from migrating or evicting your virtual machines (VMs) until you update to your target EUS version.
 
diff --git a/modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc b/modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc
@@ -3,16 +3,16 @@
 // * virt/updating/upgrading-virt.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="virt-preventing-workload-updates-during-eus-update_{context}"]
-= Preventing workload updates during an EUS-to-EUS update
+[id="virt-preventing-workload-updates-during-control-plane-only-update_{context}"]
+= Preventing workload updates during a Control Plane Only update
 
 When you update from one Extended Update Support (EUS) version to the next, you must manually disable automatic workload updates to prevent {VirtProductName} from migrating or evicting workloads during the update process.
 
 .Prerequisites
 
 * You are running an EUS version of {product-title} and want to update to the next EUS version. You have not yet updated to the odd-numbered version in between.
 
-* You read "Preparing to perform an EUS-to-EUS update" and learned the caveats and requirements that pertain to your {product-title} cluster.
+* You read "Preparing to perform a Control Plane Only update" and learned the caveats and requirements that pertain to your {product-title} cluster.
 
 * You paused the worker nodes' machine config pools as directed by the {product-title} documentation.
 
diff --git a/updating/updating_a_cluster/control-plane-only-update.adoc b/updating/updating_a_cluster/control-plane-only-update.adoc
diff --git a/updating/updating_a_cluster/updating-cluster-cli.adoc b/updating/updating_a_cluster/updating-cluster-cli.adoc
diff --git a/virt/updating/upgrading-virt.adoc b/virt/updating/upgrading-virt.adoc
