Merge pull request #57886 from obrown1205/eus_pageUpdates

OSDOCS#5593: Updated EUS-to-EUS update pages to be version agnostic and follow correct pro…

Author: jeana-redhat

modules/updating-eus-to-eus-upgrade-cli.adoc

@@ -18,7 +18,7 @@ It is highly discouraged to skip this prerequisite. If the OpenShift CLI (`oc`)
 
 .Procedure
 
-. Using the Administrator perspective on the web console, update any Operator Lifecycle Manager (OLM) Operators to the versions that are compatible with the version you are updating to. You can find more information on how to perform this action in "Updating installed Operators"; see "Additional resources".
+. Using the Administrator perspective on the web console, update any Operator Lifecycle Manager (OLM) Operators to the versions that are compatible with your intended updated version. You can find more information on how to perform this action in "Updating installed Operators"; see "Additional resources".
 
 . Verify that all machine config pools display a status of `UPDATED` and that no machine config pool displays a status of `UPDATING`.
 To view the status of all machine config pools, run the following command:
@@ -37,18 +37,18 @@ master   rendered-master-ecbb9582781c1091e1c9f19d50cf836c       True  	  False
 worker   rendered-worker-00a3f0c68ae94e747193156b491553d5       True  	  False
 ----
 
-. Change to the `eus-4.12` channel by running the following command:
+. Your current version is <4.y>, and your intended version to update is <4.y+2>. Change to the `eus-<4.y+2>` channel by running the following command:
 +
 [source,terminal]
 ----
-$ oc adm upgrade channel eus-4.12
+$ oc adm upgrade channel eus-<4.y+2>
 ----
 +
 [NOTE]
 ====
 
-If you receive an error message indicating that `eus-4.12` is not one of the
-available channels, this indicates that Red Hat is still rolling out 4.10 to 4.12 EUS updates.
+If you receive an error message indicating that `eus-<4.y+2>` is not one of the
+available channels, this indicates that Red Hat is still rolling out EUS version updates.
 This rollout process generally takes 45-90 days starting at the GA date.
 ====
 +
@@ -76,7 +76,7 @@ $ oc adm upgrade --to-latest
 +
 [source,terminal]
 ----
-Updating to latest version 4.11.18
+Updating to latest version <4.y+1.z>
 ----
 
 . Review the cluster version to ensure that the updates are complete by running the following command:
@@ -91,17 +91,17 @@ $ oc adm upgrade
 [source,terminal]
 ----
 NAME  	  VERSION  AVAILABLE  PROGRESSING   SINCE   STATUS
-version   4.11.18   True       False         6m29s   Cluster version is 4.11.18
+version   <4.y+1.z>   True       False         6m29s   Cluster version is <4.y+1.z>
 ----
 
-. Update to version 4.12 by running the following command:
+. Update to version <4.y+2> by running the following command:
 +
 [source,terminal]
 ----
 $ oc adm upgrade --to-latest
 ----
 
-. Retrieve the cluster version to ensure that the 4.12 updates are complete by running the following command:
+. Retrieve the cluster version to ensure that the <4.y+2> updates are complete by running the following command:
 +
 [source,terminal]
 ----
@@ -113,10 +113,10 @@ $ oc adm upgrade
 [source,terminal]
 ----
 NAME  	  VERSION  AVAILABLE  PROGRESSING   SINCE   STATUS
-version   4.12.1   True       False         6m29s   Cluster version is 4.12.1
+version   <4.y+2.z>   True       False         6m29s   Cluster version is <4.y+2.z>
 ----
 
-. To update your worker nodes to 4.12, unpause all previously paused machine config pools by running the following command:
+. To update your worker nodes to <4.y+2>, unpause all previously paused machine config pools by running the following command:
 +
 [source,terminal]
 ----
@@ -128,7 +128,7 @@ $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'
 If pools are not unpaused, the cluster is not permitted to update to any future minor versions, and maintenance tasks such as certificate rotation are inhibited. This puts the cluster at risk for future degradation.
 ====
 
-. Verify that your previously paused pools are updated and that the update to version 4.12 is complete by running the following command:
+. Verify that your previously paused pools are updated and that the update to version <4.y+2> is complete by running the following command:
 +
 [source,terminal]
 ----

modules/updating-eus-to-eus-upgrade-console.adoc

@@ -13,7 +13,7 @@
 
 .Procedure
 
-. Update any Operator Lifecycle Manager (OLM) Operators to versions that are compatible with both versions you are updating to. You can find more information on how to perform this action in "Preparing for an Operator update"; see "Additional resources".
+. Using the Administrator perspective on the web console, update any Operator Lifecycle Manager (OLM) Operators to the versions that are compatible with your intended updated version. You can find more information on how to perform this action in "Updating installed Operators"; see "Additional resources".
 
 . Verify that all machine config pools display a status of `Up to date` and that no machine config pool displays a status of `UPDATING`.
 +
@@ -24,21 +24,21 @@ To view the status of all machine config pools, click *Compute* -> *MachineConfi
 If your machine config pools have an `Updating` status, please wait for this status to change to `Up to date`. This process could take several minutes.
 ====
 
-. Set your channel to `eus-4.12`. 
+. Set your channel to `eus-<4.y+2>`. 
 +
 To set your channel, click *Administration* -> *Cluster Settings* -> *Channel*. You can edit your channel by clicking on the current hyperlinked channel.
 
 . Pause all worker machine pools except for the master pool. You can perform this action on the *MachineConfigPools* tab under the *Compute* page. Select the vertical ellipses next to the machine config pool you'd like to pause and click *Pause updates*.
 
-. Update to version 4.11 and complete up to the *Save* step. You can find more information on how to perform these actions in "Updating a cluster by using the web console"; see "Additional resources". 
+. Update to version <4.y+1> and complete up to the *Save* step. You can find more information on how to perform these actions in "Updating a cluster by using the web console"; see "Additional resources". 
 
-. Ensure that the 4.11 updates are complete by viewing the *Last completed version* of your cluster. You can find this information on the *Cluster Settings* page under the *Details* tab. 
+. Ensure that the <4.y+1> updates are complete by viewing the *Last completed version* of your cluster. You can find this information on the *Cluster Settings* page under the *Details* tab. 
 
 . If necessary, update your OLM Operators by using the Administrator perspective on the web console. You can find more information on how to perform these actions in "Updating installed Operators"; see "Additional resources".
 
-. Update to version 4.12 and complete up to the *Save* step. You can find more information on how to perform these actions in "Updating a cluster by using the web console"; see "Additional resources". 
+. Update to version <4.y+2> and complete up to the *Save* step. You can find more information on how to perform these actions in "Updating a cluster by using the web console"; see "Additional resources". 
 
-. Ensure that the 4.12 update is complete by viewing the *Last completed version* of your cluster. You can find this information on the *Cluster Settings* page under the *Details* tab. 
+. Ensure that the <4.y+2> update is complete by viewing the *Last completed version* of your cluster. You can find this information on the *Cluster Settings* page under the *Details* tab. 
 
 . Unpause all previously paused machine config pools. You can perform this action on the *MachineConfigPools* tab under the *Compute* page. Select the vertical ellipses next to the machine config pool you'd like to unpause and click *Unpause updates*. 
 +
@@ -47,7 +47,7 @@ To set your channel, click *Administration* -> *Cluster Settings* -> *Channel*.
 If pools are not unpaused, the cluster is not permitted to upgrade to any future minor versions, and maintenance tasks such as certificate rotation are inhibited. This puts the cluster at risk for future degradation.
 ====
 
-. Verify that your previously paused pools are updated and that your cluster has completed the update to version 4.12. 
+. Verify that your previously paused pools are updated and that your cluster has completed the update to version <4.y+2>. 
 +
 You can verify that your pools have updated on the *MachineConfigPools* tab under the *Compute* page by confirming that the *Update status* has a value of *Up to date*.
 +

updating/preparing-eus-eus-upgrade.adoc

@@ -7,20 +7,23 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 Due to fundamental Kubernetes design, all {product-title} updates between minor versions must be serialized.
-You must update from {product-title} 4.10 to 4.11 and then to 4.12. You cannot update from {product-title} 4.10 to 4.12 directly.
-However, beginning with the update from {product-title} 4.10 to 4.11 to 4.12, administrators who wish to update between two Extended Update Support (EUS) versions can do so incurring only a single reboot of non-control plane hosts.
+You must update from {product-title} <4.y> to <4.y+1>, and then to <4.y+2>. You cannot update from {product-title} <4.y> to <4.y+2> directly.
+However, administrators who want to update between two Extended Update Support (EUS) versions can do so incurring only a single reboot of non-control plane hosts.
+
+[IMPORTANT]
+====
+EUS-to-EUS updates are only viable between *even-numbered minor versions* of {product-title}.
+====
 
 There are a number of caveats to consider when attempting an EUS-to-EUS update.
 
 * EUS-to-EUS updates are only offered after updates between all versions involved have been made available in `stable` channels.
 * If you encounter issues during or after upgrading to the odd-numbered minor version but before upgrading to the next even-numbered version, then remediation of those issues may require that non-control plane hosts complete the update to the odd-numbered version before moving forward.
 * You can do a partial update by updating the worker or custom pool nodes to accommodate the time it takes for maintenance.
 * You can complete the update process during multiple maintenance windows by pausing at intermediate steps. However, plan to complete the entire update within 60 days. This is critical to ensure that normal cluster automation processes are completed including those associated with certificate rotation.
-* Support for RHEL7 workers was removed in {product-title} 4.10 and replaced with RHEL8 workers, therefore EUS-to-EUS updates are not available for clusters with RHEL7 workers. 
-+
-Verify that no RHEL7 workers are present in the 4.10 cluster before performing an EUS-to-EUS upgrade to 4.12. You must replace RHEL7 workers with RHEL8 or RHCOS workers before upgrading to {product-title} 4.12. Red Hat does not support in-place RHEL7 to RHEL8 updates for RHEL workers; those hosts must be replaced with a clean operating system install. 
 
-* Node components are not updated to {product-title} 4.11. Do not expect all features and bugs fixed in {product-title} 4.11 to be made available until you complete the update to {product-title} 4.12 and enable all MachineConfigPools to update.
+* Until the machine config pools are unpaused and the update is complete, some features and bugs fixes in <4.y+1> and <4.y+2> of {product-title} are not available.
+
 * All the clusters might update using EUS channels for a conventional update without pools paused, but only clusters with non control-plane `MachineConfigPools` objects can do EUS-to-EUS update with pools paused.
 
 include::modules/updating-eus-to-eus-upgrade.adoc[leveloffset=+1]