JIRA-OSDOCS3322: Updated the cluster upgrade content per the UI changes

sayjadha · sayjadha · commit 60a20caf8079 · 2022-06-21T15:51:12.000-04:00
and incorporated tech. and peer feedback
diff --git a/_topic_maps/_topic_map_rosa.yml b/_topic_maps/_topic_map_rosa.yml
@@ -243,9 +243,9 @@ Name: Upgrading
 Dir: upgrading
 Distros: openshift-rosa
 Topics:
-#- Name: Preparing to upgrade ROSA to 4.9
-#  File: rosa-upgrading-cluster-prepare
-#  Distros: openshift-rosa
+- Name: Preparing to upgrade ROSA to 4.9
+  File: rosa-upgrading-cluster-prepare
+  Distros: openshift-rosa
 - Name: Upgrading ROSA with STS
   File: rosa-upgrading-sts
 - Name: Upgrading ROSA
diff --git a/modules/osd-create-cluster-ccs.adoc b/modules/osd-create-cluster-ccs.adoc
@@ -220,6 +220,11 @@ CIDR configurations cannot be changed later. Confirm your selections with your n
 You can review the end-of-life dates in the update life cycle documentation for {product-title}. For more information, see _{product-title} update life cycle_.
 ====
 +
+.. Provide administrator approval based on your cluster update method:
+** Individual updates: If you select an update version that requires approval, provide an administrator’s acknowledgment and click *Approve and continue*.
+** Recurring updates: If you selected recurring updates for your cluster, provide an administrator’s acknowledgment and click *Approve and continue*. {cluster-manager} does not start scheduled y-stream updates for minor versions without receiving an administrator’s acknowledgment.
++
+For information about administrator acknowledgment, see xref:./../upgrading/osd-upgrading-cluster-prepare.adoc#upgrade-49-acknowledgement_osd-updating-cluster-prepare[Administrator acknowledgment when upgrading to OpenShift 4.9].
 .. If you opted for recurring updates, select a preferred day of the week and upgrade start time in UTC from the drop-down menus.
 .. Optional: You can set a grace period for *Node draining* during cluster upgrades. A *1 hour* grace period is set by default.
 .. Click *Next*.
diff --git a/modules/osd-create-cluster-red-hat-account.adoc b/modules/osd-create-cluster-red-hat-account.adoc
@@ -105,6 +105,11 @@ If the cluster privacy is set to *Private*, you cannot access your cluster until
 You can review the end-of-life dates in the update life cycle documentation for {product-title}. For more information, see _{product-title} update life cycle_.
 ====
 +
+.. Provide administrator approval based on your cluster update method:
+** Individual updates: If you select an update version that requires approval, provide an administrator’s acknowledgment and click *Approve and continue*.
+** Recurring updates: If you selected recurring updates for your cluster, provide an administrator’s acknowledgment and click *Approve and continue*. {cluster-manager} does not start scheduled y-stream updates for minor versions without receiving an administrator’s acknowledgment.
++
+For information about administrator acknowledgment, see xref:./../upgrading/osd-upgrading-cluster-prepare.adoc#upgrade-49-acknowledgement_osd-updating-cluster-prepare[Administrator acknowledgment when upgrading to OpenShift 4.9].
 .. If you opted for recurring updates, select a preferred day of the week and upgrade start time in UTC from the drop-down menus.
 .. Optional: You can set a grace period for *Node draining* during cluster upgrades. A *1 hour* grace period is set by default.
 .. Click *Next*.
diff --git a/modules/rosa-upgrading-automatic-ocm.adoc b/modules/rosa-upgrading-automatic-ocm.adoc
@@ -5,16 +5,20 @@
 
 :_content-type: PROCEDURE
 [id="rosa-scheduling-upgrade_{context}"]
-= Scheduling automatic upgrades
+= Scheduling recurring upgrades for your cluster
 
-You can schedule automatic upgrades for a {product-title} cluster through {cluster-manager-first} console.
+You can schedule recurring, automatic upgrades for z-stream patch versions for your {product-title} cluster through the {cluster-manager} console.
 
 .Procedure
 
 . Log in to {cluster-manager-url}.
 . Select a cluster to upgrade.
 . Click the *Settings* tab.
-. In the *Update strategy* pane, click *Automatic* and select a preferred day of the week and start time for the automatic upgrades.
+. In the *Update strategy* pane, select *Recurring updates*.
+. Select a preferred day of the week and start time for the upgrade, when updates are available.
+. Provide an administrator’s acknowledgment and click *Approve and continue*. {cluster-manager} does not start scheduled y-stream updates for minor versions without receiving an administrator’s acknowledgment.
++
+For information about administrator acknowledgment, see xref:./../upgrading/rosa-upgrading-cluster-prepare.adoc#upgrade-49-acknowledgement_rosa-updating-cluster-prepare[Administrator acknowledgment when upgrading to OpenShift 4.9].
 . In the *Node draining* pane, select a grace period interval from the list. The grace period enables the nodes to gracefully drain before forcing the pod eviction. The default is *1 hour*.
 . In the *Update strategy* pane, click *Save* to apply your update strategy.
 +
diff --git a/modules/rosa-upgrading-manual-ocm.adoc b/modules/rosa-upgrading-manual-ocm.adoc
@@ -9,13 +9,13 @@ endif::[]
 
 :_content-type: PROCEDURE
 [id="rosa-upgrade-ocm_{context}"]
-= Upgrading using the console
+= Scheduling individual upgrades through the {cluster-manager} console
 
-You can upgrade a {product-title} cluster
+You can schedule upgrades for a {product-title} cluster
 ifdef::sts[]
 that uses the AWS Security Token Service (STS)
 endif::sts[]
-manually by using {cluster-manager} console.
+manually one time by using {cluster-manager} console.
 
 ifdef::sts[]
 .Prerequisites
@@ -28,7 +28,11 @@ endif::sts[]
 . Log in to {cluster-manager-url}.
 . Select a cluster to upgrade.
 . Click the *Settings* tab.
-. In the *Update strategy* pane, click *Manual* or *Individual Updates*.
+. In the *Update strategy* pane, select *Individual Updates*.
+. Select the version you want to upgrade your cluster to. Recommended cluster upgrades appear in the UI.
+. If you select an update version that requires approval, provide an administrator’s acknowledgment and click *Approve and continue*.
++
+For information about administrator acknowledgment, see xref:./../upgrading/rosa-upgrading-cluster-prepare.adoc#upgrade-49-acknowledgement_rosa-updating-cluster-prepare[Administrator acknowledgment when upgrading to OpenShift 4.9].
 . In the *Node draining* pane, select a grace period interval from the list. The grace period enables the nodes to gracefully drain before forcing the pod eviction. The default is *1 hour*.
 . In the *Update strategy* pane, click *Save* to apply your update strategy.
 . In the *Update status* pane, review the *Update available* information and click *Update*.
diff --git a/modules/upgrade-auto.adoc b/modules/upgrade-auto.adoc
@@ -6,27 +6,29 @@
 :_content-type: PROCEDURE
 [id="upgrade-auto_{context}"]
 
-= Automatically upgrading your cluster through {cluster-manager-first}
+= Scheduling recurring upgrades for your cluster
 
 
-You can use {cluster-manager} to automatically upgrade your {product-title} cluster on a weekly basis. Based on upstream changes, there might be times when no updates are released. Therefore, no upgrade occurs for that week.
+You can use {cluster-manager} to schedule recurring, automatic upgrades for z-stream patch versions for your {product-title} cluster. Based on upstream changes, there might be times when no updates are released. Therefore, no upgrade occurs for that week.
 
 .Procedure
 
 . From {console-red-hat}, select your cluster from the clusters list.
 
 . Click the *Upgrade settings* tab to access the upgrade operator.
 
-. To schedule automatic upgrades, select *Automatic*.
+. To schedule recurring upgrades, select *Recurring updates*.
+
+. Provide an administrator’s acknowledgment and click *Approve and continue*. {cluster-manager} does not start scheduled y-stream updates for minor versions without receiving an administrator’s acknowledgment.
 
 . Specify the day of the week and the time you want your cluster to upgrade.
 
 . Click *Save*.
 
 . Optional: Set a grace period for *Node draining* by selecting a designated amount of time from the drop down list. A *1 hour* grace period is set by default.
 
-. To edit an existing automatic upgrade policy, edit the preferred day or start time from the *Upgrade Settings* tab. Click *Save*.
+. To edit an existing recurring upgrade policy, edit the preferred day or start time from the *Upgrade Settings* tab. Click *Save*.
 
-. To cancel an automatic upgrade policy, switch the upgrade method to manual from the *Upgrade Settings* tab. Click *Save*.
+. To cancel a recurring upgrade policy, switch the upgrade method to individual from the *Upgrade Settings* tab. Click *Save*.
 
 On the *Upgrade settings* tab, the *Upgrade status* box indicates that an upgrade is scheduled. The date and time of the next scheduled update is listed.
diff --git a/modules/upgrade-manual.adoc b/modules/upgrade-manual.adoc
@@ -6,10 +6,10 @@
 :_content-type: PROCEDURE
 [id="upgrade-manual_{context}"]
 
-= Manually upgrading your cluster through {cluster-manager-first}
+= Scheduling individual upgrades for your cluster
 
 
-You can use {cluster-manager} to manually upgrade your {product-title} cluster.
+You can use {cluster-manager} to manually upgrade your {product-title} cluster one time.
 
 
 .Procedure
@@ -18,9 +18,14 @@ You can use {cluster-manager} to manually upgrade your {product-title} cluster.
 
 . Click the *Upgrade settings* tab to access the upgrade operator. You can also update your cluster from the *Overview* tab by clicking *Update* next to the cluster version under the *Details* heading.
 
+
+. To schedule an individual upgrade, select *Individual updates*.
+
 . Click *Update* in the *Update Status* box.
 
-. Select the version you want to upgrade your cluster to. Recommended cluster upgrades will be notated in the UI. To learn more about each available upgrade version, click *View release notes*.
+. Select the version you want to upgrade your cluster to. Recommended cluster upgrades appear in the UI. To learn more about each available upgrade version, click *View release notes*.
+
+. If you select an update version that requires approval, provide an administrator’s acknowledgment and click *Approve and continue*.
 
 . Click *Next*.
 
@@ -42,5 +47,5 @@ The same upgrade details are available on the *Upgrade settings* tab under the *
 
 [WARNING]
 ====
-In the event that a CVE or other critical issue to OpenShift Dedicated is found, all clusters are upgraded within 48 hours of the fix being released. You are notified when the fix is available and informed that the cluster will be automatically upgraded at your latest preferred start time before the 48 hour window closes. You can also upgrade manually at any time before the automatic upgrade starts.
+In the event that a CVE or other critical issue to {product-title} is found, all clusters are upgraded within 48 hours of the fix being released. You are notified when the fix is available and informed that the cluster will be automatically upgraded at your latest preferred start time before the 48 hour window closes. You can also upgrade manually at any time before the recurring upgrade starts.
 ====
diff --git a/modules/upgrade.adoc b/modules/upgrade.adoc
@@ -20,19 +20,23 @@ All Kubernetes objects and PVs in each {product-title} cluster are backed up as
 ====
 
 [id="upgrade-automatic_{context}"]
-== Automatic upgrades
+== Recurring upgrades
 
 Upgrades can be scheduled to occur automatically on a day and time specified by the cluster owner or administrator. Upgrades occur on a weekly basis, unless an upgrade is unavailable for that week.
 
+If you select recurring updates for your cluster, you must provide an administrator’s acknowledgment. {cluster-manager} does not start scheduled y-stream updates for minor versions without receiving an administrator’s acknowledgment. For information about administrator acknowledgment, see link:https://docs.openshift.com/dedicated/upgrading/osd-upgrading-cluster-prepare.html#upgrade-49-acknowledgement_osd-updating-cluster-prepare[Administrator acknowledgment when upgrading to OpenShift 4.9].
+
 [NOTE]
 ====
-Automatic upgrade policies are optional and if they are not set, the upgrade policies default to manual.
+Recurring upgrade policies are optional and if they are not set, the upgrade policies default to individual.
 ====
 
 [id="upgrade-manual_upgrades_{context}"]
-== Manual upgrades
+== Individual upgrades
+
+If you opt for individual upgrades, you are responsible for updating your cluster. If you select an update version that requires approval, you must provide an administrator’s acknowledgment. For information about administrator acknowledgment, see xref:./../upgrading/osd-upgrading-cluster-prepare.adoc#upgrade-49-acknowledgement_osd-updating-cluster-prepare[Administrator acknowledgment when upgrading to OpenShift 4.9].
 
-If you opt for manual upgrades, you are responsible for updating your cluster. If your cluster version falls too far behind, it will transition to a limited support status. For more information on OpenShift life cycle policies, see xref:../osd_architecture/osd_policy/osd-life-cycle.adoc#osd-life-cycle[{product-title} update life cycle].
+If your cluster version becomes outdated, it will transition to a limited support status. For more information on OpenShift life cycle policies, see xref:../osd_architecture/osd_policy/osd-life-cycle.adoc#osd-life-cycle[{product-title} update life cycle].
 
 [id="upgrade-notifications_{context}"]
 == Upgrade notifications
@@ -48,7 +52,7 @@ Every change of state also triggers an email notification to the cluster owner a
 
 [NOTE]
 ====
-For automatic upgrades, you will also receive email notifications before the upgrade occurs based on the following cadence:
+For recurring upgrades, you will also receive email notifications before the upgrade occurs based on the following cadence:
 
 * 2 week notice
 * 1 week notice
diff --git a/upgrading/rosa-upgrading-sts.adoc b/upgrading/rosa-upgrading-sts.adoc
@@ -16,8 +16,8 @@ To plan an upgrade, review the xref:../rosa_architecture/rosa_policy_service_def
 
 There are two methods to upgrade {product-title} (ROSA) clusters that uses the AWS Security Token Service (STS):
 
-* Manual upgrades through the `rosa` CLI
-* Manual upgrades through the {cluster-manager} console
+* Individual upgrades through the `rosa` CLI
+* Individual upgrades through the {cluster-manager} console
 
 [NOTE]
 ====
diff --git a/upgrading/rosa-upgrading.adoc b/upgrading/rosa-upgrading.adoc
@@ -15,24 +15,15 @@ To plan an upgrade, review the xref:../rosa_architecture/rosa_policy_service_def
 == Upgrading a ROSA cluster
 There are three methods to upgrade {product-title} (ROSA) clusters:
 
-* Manual upgrades through the `rosa` CLI
-* Manual upgrades through the {cluster-manager} console
-* Automatic upgrades through the {cluster-manager} console
-
-Remove
+* Individual upgrades through the `rosa` CLI
+* Individual upgrades through the {cluster-manager-url} console
+* Recurring upgrades through the {cluster-manager-url} console
 
 [NOTE]
 ====
 For steps to upgrade a ROSA cluster that uses the AWS Security Token Service (STS), see xref:../upgrading/rosa-upgrading-sts.adoc#rosa-upgrading-sts[Upgrading ROSA clusters with STS].
 ====
 
-
-There are three methods to upgrade {product-title} (ROSA) clusters:
-
-* Manual upgrades through the `rosa` CLI
-* Manual upgrades through the {cluster-manager-url} console
-* Automatic upgrades through the {cluster-manager-url} console
-
 include::modules/rosa-upgrading-cli-tutorial.adoc[leveloffset=+2]
 include::modules/rosa-upgrading-manual-ocm.adoc[leveloffset=+2]
 include::modules/rosa-upgrading-automatic-ocm.adoc[leveloffset=+2]
