mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
70 lines
3.4 KiB
Plaintext
70 lines
3.4 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * virt/updating/upgrading-virt.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
|
|
[id="virt-about-upgrading-virt_{context}"]
|
|
= About updating {VirtProductName}
|
|
|
|
[role="_abstract"]
|
|
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.
|
|
|
|
[NOTE]
|
|
====
|
|
Both settings can impact supportability.
|
|
====
|
|
|
|
[id="recommended-settings_{context}"]
|
|
== Recommended settings
|
|
|
|
To maintain a supportable environment, use the following settings:
|
|
|
|
* Update channel: *stable*
|
|
* Approval strategy: *Automatic*
|
|
|
|
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.
|
|
|
|
[NOTE]
|
|
====
|
|
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}.
|
|
====
|
|
|
|
[id="what-to-expect_{context}"]
|
|
== What to expect
|
|
|
|
You can anticipate update behavior in {VirtProductName}, including duration, automation, and data preservation.
|
|
|
|
* The amount of time an update takes to complete depends on your network
|
|
connection. Most automatic updates complete within fifteen minutes.
|
|
|
|
* Updating {VirtProductName} does not interrupt network connections.
|
|
|
|
* Data volumes and their associated persistent volume claims are preserved during an update.
|
|
|
|
ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
|
|
[IMPORTANT]
|
|
====
|
|
If you have virtual machines running that use hostpath provisioner storage, they cannot be live migrated and might block an {product-title} cluster update.
|
|
|
|
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`.
|
|
====
|
|
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
|
|
ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
|
|
[IMPORTANT]
|
|
====
|
|
If you have virtual machines running that use AWS Elastic Block Store (EBS) storage, they cannot be live migrated and might block an {product-title} cluster update.
|
|
|
|
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`.
|
|
====
|
|
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
|
|
|
|
[id="how-updates-work_{context}"]
|
|
== How updates work
|
|
|
|
Learn how the {VirtProductName} Operator is updated through the Operator Lifecycle Manager (OLM) and how update channels and approval strategies affect upgrade behavior.
|
|
|
|
* 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.
|
|
|
|
* 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}.
|