Skip to content

Commit 37707d9

Browse files
ousleypousleyp
authored
Merge pull request #90163 from ousleyp/update-improvement-15
[enterprise-4.15] update docs with candidate channel + rework
2 parents cdc9330 + c5a584d commit 37707d9

9 files changed

+100
-36
lines changed

‎modules/virt-about-control-plane-only-updates.adoc

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -4,16 +4,18 @@
44

55
:_mod-docs-content-type: CONCEPT
66
[id="virt-about-control-plane-only-updates_{context}"]
7-
= About Control Plane Only updates
7+
= Control Plane Only updates
88

99
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.
1010

1111
After you update from the source EUS version to the next odd-numbered minor version, you must sequentially update {VirtProductName} to all z-stream releases of that minor version that are on your update path. When you have upgraded to the latest applicable z-stream version, you can then update {product-title} to the target EUS minor version.
1212

1313
When the {product-title} update succeeds, the corresponding update for {VirtProductName} becomes available. You can now update {VirtProductName} to the target EUS version.
1414

15-
[id="preparing-to-update_{context}"]
16-
== Preparing to update
15+
For more information about EUS versions, see the link:https://access.redhat.com/support/policy/updates/openshift[Red Hat OpenShift Container Platform Life Cycle Policy].
16+
17+
[id="prerequisites_{context}"]
18+
== Prerequisites
1719

1820
Before beginning a Control Plane Only update, you must:
1921

‎modules/virt-about-upgrading-virt.adoc

Lines changed: 23 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -6,22 +6,32 @@
66
[id="virt-about-upgrading-virt_{context}"]
77
= About updating {VirtProductName}
88

9-
* Operator Lifecycle Manager (OLM) manages the lifecycle of the {VirtProductName} Operator. The Marketplace Operator, which is deployed during {product-title} installation, makes external Operators available to your cluster.
9+
When you install {VirtProductName}, you select an update channel and an approval strategy. The update channel determines the versions that {VirtProductName} will be updated to. The approval strategy setting determines whether updates occur automatically or require manual approval. Both settings can impact supportability.
10+
11+
[id="recommended-settings_{context}"]
12+
== Recommended settings
13+
14+
To maintain a supportable environment, use the following settings:
1015

11-
* OLM provides z-stream and minor version updates for {VirtProductName}. Minor version updates become available when you update {product-title} to the next minor version. You cannot update {VirtProductName} to the next minor version without first updating {product-title}.
16+
* Update channel: *stable*
17+
* Approval strategy: *Automatic*
1218

13-
* {VirtProductName} subscriptions use a single update channel that is named *stable*. The *stable* channel ensures that your {VirtProductName} and {product-title} versions are compatible.
19+
With these settings, the update process automatically starts when a new version of the Operator is available in the *stable* channel. This ensures that your {VirtProductName} and {product-title} versions remain compatible, and that your version of {VirtProductName} is suitable for production environments.
1420

15-
* If your subscription's approval strategy is set to *Automatic*, the update process starts as soon as a new version of the Operator is available in the *stable* channel. It is highly recommended to use the *Automatic* approval strategy to maintain a supportable environment. Each minor version of {VirtProductName} is only supported if you run the corresponding {product-title} version. For example, you must run {VirtProductName} {VirtVersion} on {product-title} {VirtVersion}.
21+
[NOTE]
22+
====
23+
Each minor version of {VirtProductName} is supported only if you run the corresponding {product-title} version. For example, you must run {VirtProductName} {VirtVersion} on {product-title} {VirtVersion}.
24+
====
1625

17-
** Though it is possible to select the *Manual* approval strategy, this is not recommended because it risks the supportability and functionality of your cluster. With the *Manual* approval strategy, you must manually approve every pending update. If {product-title} and {VirtProductName} updates are out of sync, your cluster becomes unsupported.
26+
[id="what-to-expect_{context}"]
27+
== What to expect
1828

1929
* The amount of time an update takes to complete depends on your network
2030
connection. Most automatic updates complete within fifteen minutes.
2131

2232
* Updating {VirtProductName} does not interrupt network connections.
2333

24-
* Data volumes and their associated persistent volume claims are preserved during update.
34+
* Data volumes and their associated persistent volume claims are preserved during an update.
2535

2636
ifndef::openshift-rosa,openshift-dedicated[]
2737
[IMPORTANT]
@@ -39,3 +49,10 @@ If you have virtual machines running that use AWS Elastic Block Store (EBS) stor
3949
As a workaround, you can reconfigure the virtual machines so that they can be powered off automatically during a cluster update. Set the `evictionStrategy` field to `None` and the `runStrategy` field to `Always`.
4050
====
4151
endif::openshift-rosa,openshift-dedicated[]
52+
53+
[id="how-updates-work_{context}"]
54+
== How updates work
55+
56+
* Operator Lifecycle Manager (OLM) manages the lifecycle of the {VirtProductName} Operator. The Marketplace Operator, which is deployed during {product-title} installation, makes external Operators available to your cluster.
57+
58+
* OLM provides z-stream and minor version updates for {VirtProductName}. Minor version updates become available when you update {product-title} to the next minor version. You cannot update {VirtProductName} to the next minor version without first updating {product-title}.

‎modules/virt-about-workload-updates.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
:_mod-docs-content-type: CONCEPT
66
[id="virt-about-workload-updates_{context}"]
7-
= About workload updates
7+
= VM workload updates
88

99
When you update {VirtProductName}, virtual machine workloads, including `libvirt`, `virt-launcher`, and `qemu`, update automatically if they support live migration.
1010

‎modules/virt-changing-update-settings.adoc

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/updating/upgrading-virt.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="virt-changing-update-settings_{context}"]
7+
= Changing update settings
8+
9+
You can change the update channel and approval strategy for your {VirtProductName} Operator subscription by using the web console.
10+
11+
.Prerequisites
12+
13+
* You have installed the {VirtProductName} Operator.
14+
* You have administrator permissions.
15+
16+
.Procedure
17+
18+
. Click *Operators* -> *Installed Operators*.
19+
20+
. Select *{VirtProductName}* from the list.
21+
22+
. Click the *Subscription* tab.
23+
24+
. In the *Subscription details* section, click the setting that you want to change. For example, to change the approval strategy from *Manual* to *Automatic*, click *Manual*.
25+
26+
. In the window that opens, select the new update channel or approval strategy.
27+
28+
. Click *Save*.

‎modules/virt-manual-approval-strategy.adoc

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/updating/upgrading-virt.adoc
4+
5+
:_mod-docs-content-type: CONCEPT
6+
[id="virt-manual-approval-strategy_{context}"]
7+
= Manual approval strategy
8+
9+
If you use the *Manual* approval strategy, you must manually approve every pending update. If {product-title} and {VirtProductName} updates are out of sync, your cluster becomes unsupported. To avoid risking the supportability and functionality of your cluster, use the *Automatic* approval strategy.
10+
11+
If you must use the *Manual* approval strategy, maintain a supportable cluster by approving pending Operator updates as soon as they become available.

‎modules/virt-monitoring-upgrade-status.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,9 +4,9 @@
44

55
:_mod-docs-content-type: PROCEDURE
66
[id="virt-monitoring-upgrade-status_{context}"]
7-
= Monitoring {VirtProductName} upgrade status
7+
= Monitoring update status
88

9-
To monitor the status of a {VirtProductName} Operator upgrade, watch the cluster service version (CSV) `PHASE`. You can also monitor the CSV conditions in the web console or by running the command provided here.
9+
To monitor the status of a {VirtProductName} Operator update, watch the cluster service version (CSV) `PHASE`. You can also monitor the CSV conditions in the web console or by running the command provided here.
1010

1111
[NOTE]
1212
====

‎modules/virt-rhel-9.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
:_mod-docs-content-type: CONCEPT
66
[id="virt-rhel-9_{context}"]
7-
= {VirtProductName} on {op-system-base} 9
7+
= {op-system-base} 9 compatibility
88

99
{VirtProductName} {VirtVersion} is based on {op-system-base-full} 9. You can update to {VirtProductName} {VirtVersion} from a version that was based on {op-system-base} 8 by following the standard {VirtProductName} update procedure. No additional steps are required.
1010

‎modules/virt-viewing-outdated-workloads.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,9 +4,9 @@
44

55
:_mod-docs-content-type: PROCEDURE
66
[id="virt-viewing-outdated-workloads_{context}"]
7-
= Viewing outdated {VirtProductName} workloads
7+
= Viewing outdated VM workloads
88

9-
You can view a list of outdated workloads by using the CLI.
9+
You can view a list of outdated virtual machine (VM) workloads by using the CLI.
1010

1111
[NOTE]
1212
====

‎virt/updating/upgrading-virt.adoc

Lines changed: 27 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -6,40 +6,46 @@ include::_attributes/common-attributes.adoc[]
66

77
toc::[]
88

9-
Learn how Operator Lifecycle Manager (OLM) delivers z-stream and minor version updates for {VirtProductName}.
10-
11-
include::modules/virt-rhel-9.adoc[leveloffset=+1]
9+
Learn how to keep {VirtProductName} updated and compatible with {product-title}.
1210

1311
include::modules/virt-about-upgrading-virt.adoc[leveloffset=+1]
1412

15-
include::modules/virt-about-workload-updates.adoc[leveloffset=+2]
13+
include::modules/virt-rhel-9.adoc[leveloffset=+2]
1614

17-
ifndef::openshift-rosa,openshift-dedicated,openshift-origin[]
18-
include::modules/virt-about-control-plane-only-updates.adoc[leveloffset=+2]
15+
include::modules/virt-monitoring-upgrade-status.adoc[leveloffset=+1]
1916

20-
Learn more about xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[performing a Control Plane Only update].
17+
// workload updates
18+
include::modules/virt-about-workload-updates.adoc[leveloffset=+1]
2119

22-
include::modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc[leveloffset=+1]
23-
endif::openshift-rosa,openshift-dedicated,openshift-origin[]
20+
include::modules/virt-configuring-workload-update-methods.adoc[leveloffset=+2]
2421

25-
include::modules/virt-configuring-workload-update-methods.adoc[leveloffset=+1]
22+
include::modules/virt-viewing-outdated-workloads.adoc[leveloffset=+2]
2623

27-
[id="approving-operator-upgrades_upgrading-virt"]
28-
== Approving pending Operator updates
24+
[NOTE]
25+
====
26+
To ensure that VMIs update automatically, configure workload updates.
27+
====
2928

30-
include::modules/olm-approving-pending-upgrade.adoc[leveloffset=+2]
29+
// control plane updates
3130

32-
[id="monitoring-upgrade-status_upgrading-virt"]
33-
== Monitoring update status
31+
ifndef::openshift-rosa,openshift-dedicated,openshift-origin[]
32+
include::modules/virt-about-control-plane-only-updates.adoc[leveloffset=+1]
3433

35-
include::modules/virt-monitoring-upgrade-status.adoc[leveloffset=+2]
34+
Learn more about xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update].
3635

37-
include::modules/virt-viewing-outdated-workloads.adoc[leveloffset=+2]
36+
include::modules/virt-preventing-workload-updates-during-control-plane-only-update.adoc[leveloffset=+2]
37+
endif::openshift-rosa,openshift-dedicated,openshift-origin[]
3838

39-
[NOTE]
40-
====
41-
Configure workload updates to ensure that VMIs update automatically.
42-
====
39+
[id="advanced-options_upgrading-virt"]
40+
== Advanced options
41+
42+
The *stable* release channel and the *Automatic* approval strategy are recommended for most {VirtProductName} installations. Use other settings only if you understand the risks.
43+
44+
include::modules/virt-changing-update-settings.adoc[leveloffset=+2]
45+
46+
include::modules/virt-manual-approval-strategy.adoc[leveloffset=+2]
47+
48+
include::modules/olm-approving-pending-upgrade.adoc[leveloffset=+2]
4349

4450
[id="additional-resources_upgrading-virt"]
4551
[role="_additional-resources"]

0 commit comments

Comments
 (0)