Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JIRA-OSDOCS3322: Updated the steps for cluster upgrades per the UI changes #44907

Merged
merged 1 commit into from
Jun 21, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions _topic_maps/_topic_map_rosa.yml
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
5 changes: 5 additions & 0 deletions modules/osd-create-cluster-ccs.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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*.
sayjadha marked this conversation as resolved.
Show resolved Hide resolved
** 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*.
Expand Down
5 changes: 5 additions & 0 deletions modules/osd-create-cluster-red-hat-account.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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*.
sayjadha marked this conversation as resolved.
Show resolved Hide resolved
** 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*.
Expand Down
10 changes: 7 additions & 3 deletions modules/rosa-upgrading-automatic-ocm.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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*.
sayjadha marked this conversation as resolved.
Show resolved Hide resolved
. 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a difference between upgrade and update?
start time for the upgrade
when updates are available
scheduled y-stream updates

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requires a larger conversation with the PM team and the decision will impact more topics than the ones touched on in this PR. I'll create a separate PR to track the update vs upgrade term change, but meanwhile, this PR needs to be merged. Thank you.

+
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.
+
Expand Down
12 changes: 8 additions & 4 deletions modules/rosa-upgrading-manual-ocm.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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*.
sayjadha marked this conversation as resolved.
Show resolved Hide resolved
. 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*.
Expand Down
12 changes: 7 additions & 5 deletions modules/upgrade-auto.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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.
13 changes: 9 additions & 4 deletions modules/upgrade-manual.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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*.

Expand All @@ -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.
====
14 changes: 9 additions & 5 deletions modules/upgrade.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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].
sayjadha marked this conversation as resolved.
Show resolved Hide resolved

[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
Expand All @@ -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
Expand Down
4 changes: 2 additions & 2 deletions upgrading/rosa-upgrading-sts.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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]
====
Expand Down
15 changes: 3 additions & 12 deletions upgrading/rosa-upgrading.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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]