Skip to content

Commit 4d73dde

Browse files
ousleypousleyp
authored
Merge pull request #38149 from ousleyp/tp-auto-workload-updates
BZ2017573: CNV-9800 is now TP for 4.9
2 parents 7dc3088 + ef4010a commit 4d73dde

File tree

4 files changed

+66
-45
lines changed

4 files changed

+66
-45
lines changed

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

Lines changed: 1 addition & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -5,9 +5,6 @@
55
[id="virt-about-upgrading-virt_{context}"]
66
= About upgrading {VirtProductName}
77

8-
[id="how-upgrades-work_{context}"]
9-
== How {VirtProductName} upgrades work
10-
118
* 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.
129

1310
* OLM provides z-stream and minor version updates for {VirtProductName}. Minor version updates become available when you upgrade {product-title} to the next minor version. You cannot upgrade {VirtProductName} to the next minor version without first upgrading {product-title}.
@@ -21,34 +18,10 @@
2118
* The amount of time an update takes to complete depends on your network
2219
connection. Most automatic updates complete within fifteen minutes.
2320

24-
[id="how-upgrades-affect-cluster_{context}"]
25-
== How {VirtProductName} upgrades affect your cluster
26-
27-
* When you upgrade {VirtProductName}, virtual machine workloads including `libvirt`, `virt-launcher`, and `qemu` update automatically if they support live migration.
28-
+
29-
[NOTE]
30-
====
31-
Each virtual machine has a `virt-launcher` pod that runs the virtual machine
32-
instance. The `virt-launcher` pod runs an instance of `libvirt`, which is
33-
used to manage the virtual machine process.
34-
====
35-
36-
** There are two supported workload update methods: `LiveMigrate` and `Evict`. By default, only `LiveMigrate` is enabled, which means that:
37-
38-
*** Virtual machine instances (VMIs) that support live migration are migrated during the upgrade process.
39-
40-
*** VMIs are not updated at all if the following conditions are both true:
41-
42-
**** The VMI does not support live migration.
43-
44-
**** The VMI is configured to use the `LiveMigrate` eviction strategy.
45-
46-
** You can configure how workloads are updated by editing the `spec.workloadUpdateStrategy` stanza of the `HyperConverged` custom resource (CR).
47-
4821
* Upgrading does not interrupt network connections.
4922

5023
* Data volumes and their associated persistent volume claims are preserved during upgrade.
51-
+
24+
5225
[IMPORTANT]
5326
====
5427
If you have virtual machines running that cannot be live migrated, they might block an {product-title} cluster upgrade.

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

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/upgrading-virt.adoc
4+
5+
[id="virt-about-workload-updates_{context}"]
6+
= About workload updates
7+
8+
* When you upgrade {VirtProductName}, virtual machine workloads including `libvirt`, `virt-launcher`, and `qemu` update automatically if they support live migration.
9+
+
10+
[NOTE]
11+
====
12+
Each virtual machine has a `virt-launcher` pod that runs the virtual machine
13+
instance. The `virt-launcher` pod runs an instance of `libvirt`, which is
14+
used to manage the virtual machine process.
15+
====
16+
17+
** There are two available workload update methods: `LiveMigrate` and `Evict`. By default, only `LiveMigrate` is enabled, which means that:
18+
19+
*** Virtual machine instances (VMIs) that support live migration are migrated during the upgrade process.
20+
21+
*** VMIs are not updated at all if the following conditions are both true:
22+
23+
**** The VMI does not support live migration.
24+
25+
**** The VMI is configured to use the `LiveMigrate` eviction strategy.
26+
27+
** You can configure how workloads are updated by editing the `spec.workloadUpdateStrategy` stanza of the `HyperConverged` custom resource (CR).

‎modules/virt-configuring-workload-update-methods.adoc

Lines changed: 14 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5,15 +5,15 @@
55
[id="virt-configuring-workload-update-methods_{context}"]
66
= Configuring workload update methods
77

8-
When you upgrade {VirtProductName}, virtual machine instance (VMI) workloads, such as `virt-launcher` pods, update automatically if they support live migration. You can configure workload update strategies or opt out of workload updates by editing the `HyperConverged` custom resource (CR).
8+
You can configure workload update methods by editing the `HyperConverged` custom resource (CR).
99

1010
.Prerequisites
1111

1212
* To use live migration as an update method, you must first enable live migration in the cluster.
1313
+
1414
[NOTE]
1515
====
16-
If a `VirtualMachineInstance` CR contains `evictionStrategy: LiveMigrate` and the VMI does not support live migration, the VMI will not update.
16+
If a `VirtualMachineInstance` CR contains `evictionStrategy: LiveMigrate` and the virtual machine instance (VMI) does not support live migration, the VMI will not update.
1717
====
1818

1919
.Procedure
@@ -40,11 +40,18 @@ spec:
4040
- Evict <3>
4141
batchEvictionSize: 10 <4>
4242
batchEvictionInterval: "1m0s" <5>
43+
...
4344
----
44-
<1> The methods that can be used to perform automated workload updates. The supported values are `LiveMigrate` and `Evict`. By default, only `LiveMigrate` is enabled. If you enable both options as shown in this example, updates use `LiveMigrate` for VMIs that support live migration and `Evict` for any VMIs that do not support live migration. To disable automatic workload updates, set `workloadUpdateMethods: []` to leave the array empty.
45-
<2> The least disruptive update method. VMIs that support live migration are updated by migrating the virtual machine (VM) guest into a new pod with the updated components enabled. If `LiveMigrate` is the only workload update method listed, VMIs that do not support live migration are not disrupted or updated. `LiveMigrate` is enabled by default.
46-
<3> A disruptive method that shuts down VMI pods during upgrade. `Evict` is the only update method available if live migration is not enabled in the cluster. If a VMI is controlled by a `VirtualMachine` object that has `runStrategy: always` configured, a new VMI is created in a new pod with updated components. `Evict` is not enabled by default.
47-
<4> The number of VMIs that can be forced to be updated at a time. The default value is `10`.
48-
<5> The interval to wait before evicting the next batch of workloads. The default value is `"1m0s"`.
45+
<1> The methods that can be used to perform automated workload updates. The available values are `LiveMigrate` and `Evict`. If you enable both options as shown in this example, updates use `LiveMigrate` for VMIs that support live migration and `Evict` for any VMIs that do not support live migration. To disable automatic workload updates, you can either remove the `workloadUpdateStrategy` stanza or set `workloadUpdateMethods: []` to leave the array empty.
46+
//NOTE: in 4.10, removing the stanza will not disable the feature.
47+
<2> The least disruptive update method. VMIs that support live migration are updated by migrating the virtual machine (VM) guest into a new pod with the updated components enabled. If `LiveMigrate` is the only workload update method listed, VMIs that do not support live migration are not disrupted or updated.
48+
<3> A disruptive method that shuts down VMI pods during upgrade. `Evict` is the only update method available if live migration is not enabled in the cluster. If a VMI is controlled by a `VirtualMachine` object that has `runStrategy: always` configured, a new VMI is created in a new pod with updated components.
49+
<4> The number of VMIs that can be forced to be updated at a time by using the `Evict` method. This does not apply to the `LiveMigrate` method.
50+
<5> The interval to wait before evicting the next batch of workloads. This does not apply to the `LiveMigrate` method.
51+
+
52+
[NOTE]
53+
====
54+
You can configure live migration limits and timeouts by editing the `spec.liveMigrationConfig` stanza of the `HyperConverged` CR.
55+
====
4956

5057
. To apply your changes, save and exit the editor.

‎virt/upgrading-virt.adoc

Lines changed: 24 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -11,16 +11,27 @@ Learn how Operator Lifecycle Manager (OLM) delivers z-stream and minor version u
1111
include::modules/virt-about-upgrading-virt.adoc[leveloffset=+1]
1212

1313
[id="configuring-workload-updates_upgrading-virt"]
14-
== Configuring workload updates
14+
== Configuring automatic workload updates
1515

16-
[NOTE]
17-
====
18-
Automatic workload updates are enabled by default in {VirtProductName} {VirtVersion}. You can opt out by following a xref:../virt/upgrading-virt.adoc#virt-opting-out-workload-updates_upgrading-virt[workaround to disable this feature] before you upgrade to {VirtVersion}.
19-
====
16+
// Uncomment this in 4.10
17+
//[NOTE]
18+
//====
19+
//Automatic workload updates are enabled by default in {VirtProductName} {VirtVersion}. You can opt out by following a xref:../virt/upgrading-virt.adoc#virt-opting-out-workload-updates_upgrading-virt[workaround to disable this feature] before you upgrade to {VirtVersion}.
20+
//====
21+
22+
// Remove TP module in 4.10
23+
ifdef::openshift-enterprise[]
24+
:FeatureName: Automatically updating workloads
25+
include::modules/technology-preview.adoc[leveloffset=+2]
26+
endif::[]
27+
28+
// Uncomment this in 4.10 if it is still relevant (describes default behavior)
29+
//include::modules/virt-about-workload-updates.adoc[leveloffset=+2]
2030
2131
include::modules/virt-configuring-workload-update-methods.adoc[leveloffset=+2]
2232
23-
include::modules/virt-opting-out-workload-updates.adoc[leveloffset=+2]
33+
// Uncomment and/or change this procedure in 4.10
34+
//include::modules/virt-opting-out-workload-updates.adoc[leveloffset=+2]
2435
2536
[id="approving-operator-upgrades_upgrading-virt"]
2637
== Approving pending Operator upgrades
@@ -34,10 +45,11 @@ include::modules/virt-monitoring-upgrade-status.adoc[leveloffset=+2]
3445
3546
include::modules/virt-viewing-outdated-workloads.adoc[leveloffset=+2]
3647
37-
[NOTE]
38-
====
39-
xref:../virt/upgrading-virt.adoc#configuring-workload-updates_upgrading-virt[Configure workload updates] to ensure that VMIs update automatically.
40-
====
48+
// Uncomment this in 4.10
49+
//[NOTE]
50+
//====
51+
//xref:../virt/upgrading-virt.adoc#configuring-workload-updates_upgrading-virt[Configure workload updates] to ensure that VMIs update automatically.
52+
//====
4153
4254
[id="additional-resources_upgrading-virt"]
4355
== Additional resources
@@ -51,3 +63,5 @@ xref:../virt/upgrading-virt.adoc#configuring-workload-updates_upgrading-virt[Con
5163
* xref:../virt/live_migration/virt-live-migration.adoc#virt-live-migration[Virtual machine live migration]
5264
5365
* xref:../virt/live_migration/virt-configuring-vmi-eviction-strategy.adoc#virt-configuring-vmi-eviction-strategy[Configuring virtual machine eviction strategy]
66+
67+
* xref:../virt/live_migration/virt-live-migration-limits.adoc#virt-configuring-live-migration-limits_virt-live-migration-limits[Configuring live migration limits and timeouts]

0 commit comments

Comments
 (0)