You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/update-conditional-web-console.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ You can view and assess the risks associated with particular updates with condit
15
15
16
16
* Pause all `MachineHealthCheck` resources.
17
17
18
-
* Your Operators that were previously installed through Operator Lifecycle Manager (OLM) are updated to their latest version in their latest channel. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update.
18
+
* You have updated all Operators previously installed through Operator Lifecycle Manager (OLM) to a version that is compatible with your target release. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See "Updating installed Operators" in the "Additional resources" section for more information on how to check compatibility and, if necessary, update the installed Operators.
19
19
20
20
* Your machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing an advanced update strategy, such as a canary rollout, an EUS update, or a control-plane update.
Copy file name to clipboardExpand all lines: modules/update-upgrading-web.adoc
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,11 +24,11 @@ link:https://access.redhat.com/downloads/content/290[in the errata section] of t
24
24
25
25
* Pause all `MachineHealthCheck` resources.
26
26
27
-
* Your Operators that were previously installed through Operator Lifecycle Manager (OLM) are updated to their latest version in their latest channel. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update.
27
+
* You have updated all Operators previously installed through Operator Lifecycle Manager (OLM) to a version that is compatible with your target release. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See "Updating installed Operators" in the "Additional resources" section for more information on how to check compatibility and, if necessary, update the installed Operators.
28
28
29
29
* Your machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
30
30
31
-
* Your {op-system-base}7 workers are replaced with {op-system-base}8 or {op-system} workers before updating to {product-title}{product-version}. RedHat does not support in-place {op-system-base}7 to {op-system-base}8 updates for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
31
+
* Your {op-system-base}7 workers are replaced with {op-system-base}8 or {op-system} workers. Red{nbsp}Hat does not support in-place {op-system-base}7 to {op-system-base}8 updates for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
32
32
33
33
.Procedure
34
34
@@ -65,7 +65,7 @@ The Input channel
65
65
+
66
66
[NOTE]
67
67
====
68
-
If you are update your cluster to the next minor version, like version 4.y to 4.(y+1), it is recommended to confirm your nodes are updated before deploying workloads that rely on a new feature. Any pools with worker nodes that are not yet updated are displayed on the *Cluster Settings* page.
68
+
If you are updating your cluster to the next minor version, for example from version 4.10 to 4.11, confirm that your nodes are updated before deploying workloads that rely on a new feature. Any pools with worker nodes that are not yet updated are displayed on the *Cluster Settings* page.
69
69
====
70
70
71
71
. After the update completes and the Cluster Version Operator refreshes the available updates, check if more updates are available in your current channel.
@@ -83,9 +83,9 @@ endif::openshift-origin[]
83
83
You might need to perform several intermediate updates until you reach the version that you want.
84
84
ifdef::rhel[]
85
85
+
86
-
[NOTE]
86
+
[IMPORTANT]
87
87
====
88
-
When you update a cluster that contains Red Hat Enterprise Linux (RHEL) worker machines, those workers temporarily become unavailable during the update process. You must run the update playbook against each RHEL machine as it enters the `NotReady` state for the cluster to finish updating.
88
+
When you update a cluster that contains {op-system-base-full}worker machines, those workers temporarily become unavailable during the update process. You must run the update playbook against each {op-system-base} machine as it enters the `NotReady` state for the cluster to finish updating.
Copy file name to clipboardExpand all lines: modules/updating-eus-to-eus-layered-products.adoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,9 +17,9 @@ Layered products refer to products that are made of multiple underlying products
17
17
18
18
As you perform an EUS-to-EUS update for the clusters of layered products and those of Operators that have been installed through OLM, you must complete the following:
19
19
20
-
. Ensure that all of your Operators previously installed through OLM are updated to their latest version in their latest channel. Updating the Operators ensures that they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. For information on how to update your Operators, see "Preparing for an Operator update" in "Additional resources".
20
+
. You have updated all Operators previously installed through Operator Lifecycle Manager (OLM) to a version that is compatible with your target release. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See "Updating installed Operators" in the "Additional resources" section for more information on how to check compatibility and, if necessary, update the installed Operators.
21
21
22
-
. Confirm the cluster version compatibility between the current and intended Operator versions. You can verify which versions your OLM Operators are compatible with by using the link:https://access.redhat.com/labs/ocpouic/?operator=logging&&ocp_versions=4.10,4.11,4.12[RedHat {product-title} Operator Update Information Checker].
22
+
. Confirm the cluster version compatibility between the current and intended Operator versions. You can verify which versions your OLM Operators are compatible with by using the link:https://access.redhat.com/labs/ocpouic/?operator=logging&&ocp_versions=4.10,4.11,4.12[Red{nbsp}Hat {product-title} Operator Update Information Checker].
23
23
24
24
As an example, here are the steps to perform an EUS-to-EUS update from <4.y> to <4.y+2> for OpenShift Data Foundation (ODF). This can be done through the CLI or web console. For information on how to update clusters through your desired interface, see _EUS-to-EUS update using the web console_ and "EUS-to-EUS update using the CLI" in "Additional resources".
For {product-title} clusters that are installed on restricted networks, also known as _disconnected clusters_, Operator Lifecycle Manager (OLM) by default cannot access the RedHat-provided OperatorHub sources hosted on remote registries because those remote sources require full internet connectivity.
9
+
For {product-title} clusters that are installed on restricted networks, also known as _disconnected clusters_, Operator Lifecycle Manager (OLM) by default cannot access the Red{nbsp}Hat-provided OperatorHub sources hosted on remote registries because those remote sources require full internet connectivity.
10
10
11
11
However, as a cluster administrator you can still enable your cluster to use OLM in a restricted network if you have a workstation that has full internet access. The workstation, which requires full internet access to pull the remote OperatorHub content, is used to prepare local mirrors of the remote sources, and push the content to a mirror registry.
12
12
@@ -27,7 +27,7 @@ While OLM can manage Operators from local sources, the ability for a given Opera
27
27
* List any related images, or other container images that the Operator might require to perform their functions, in the `relatedImages` parameter of its `ClusterServiceVersion` (CSV) object.
28
28
* Reference all specified images by a digest (SHA) and not by a tag.
29
29
30
-
You can search software on the link:https://catalog.redhat.com/software/search?p=1&deployed_as=Operator&type=Containerized%20application&badges_and_features=Disconnected[RedHat Ecosystem Catalog] for a list of RedHat Operators that support running in disconnected mode by filtering with the following selections:
30
+
You can search software on the link:https://catalog.redhat.com/software/search?p=1&deployed_as=Operator&type=Containerized%20application&badges_and_features=Disconnected[Red{nbsp}Hat Ecosystem Catalog] for a list of Red{nbsp}Hat Operators that support running in disconnected mode by filtering with the following selections:
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-enabling-operator-for-restricted-network_osdk-generating-csvs[Enabling your Operator for restricted network environments]
43
43
44
44
[id="olm-restricted-network-prereqs"]
@@ -60,7 +60,7 @@ For instructions about mirroring Operator catalogs for use with disconnected clu
60
60
61
61
[IMPORTANT]
62
62
====
63
-
As of {product-title} 4.11, the default RedHat-provided Operator catalog releases in the file-based catalog format. The default RedHat-provided Operator catalogs for {product-title} 4.6 through 4.10 released in the deprecated SQLite database format.
63
+
As of {product-title} 4.11, the default Red{nbsp}Hat-provided Operator catalog releases in the file-based catalog format. The default Red{nbsp}Hat-provided Operator catalogs for {product-title} 4.6 through 4.10 released in the deprecated SQLite database format.
64
64
65
65
The `opm` subcommands, flags, and functionality related to the SQLite database format are also deprecated and will be removed in a future release. The features are still supported and must be used for catalogs that use the deprecated SQLite database format.
* xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-accessing-images-private-registries_olm-managing-custom-catalogs[Accessing images for Operators from private registries]
76
76
* xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-catalogsource-image-template_olm-understanding-olm[Image template for custom catalog sources]
* xref:../../operators/admin/olm-upgrading-operators.adoc#olm-changing-update-channel_olm-upgrading-operators[Preparing for an Operator update]
46
-
* xref:../../updating/updating_a_cluster/updating-cluster-web-console.adoc#update-upgrading-web_updating-cluster-web-console[Updating a cluster by using the web console]
* xref:../../updating/updating_a_cluster/updating-cluster-web-console.adoc#update-upgrading-web_updating-cluster-web-console[Updating a cluster by using the web console]
* xref:../../updating/updating_a_cluster/eus-eus-update.adoc#updating-eus-to-eus-upgrade-console_eus-to-eus-update[EUS-to-EUS update using the web console]
66
65
* xref:../../updating/updating_a_cluster/eus-eus-update.adoc#updating-eus-to-eus-upgrade-cli_eus-to-eus-update[EUS-to-EUS update using the CLI]
Copy file name to clipboardExpand all lines: updating/updating_a_cluster/updating-cluster-cli.adoc
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,9 +24,9 @@ You can update, or upgrade, an {product-title} cluster within a minor version by
24
24
* Have access to the cluster as a user with `admin` privileges.
25
25
See xref:../../authentication/using-rbac.adoc#using-rbac[Using RBAC to define and apply permissions].
26
26
* Have a recent xref:../../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your update fails and you must restore your cluster to a previous state.
27
-
* Have a recent xref:../../backup_and_restore/application_backup_and_restore/installing/oadp-backup-restore-csi-snapshots.adoc[Container Storage Interface (CSI) volume snapshot] in case you need to restore persistent volumes due to a pod failure.
28
-
* Support for {op-system-base}7 workers is removed in {product-title} {product-version}. You must replace {op-system-base}7 workers with {op-system-base}8 or {op-system} workers before updating to {product-title} {product-version}. RedHat does not support in-place {op-system-base}7 to {op-system-base}8 updates for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
29
-
* Ensure all Operators previously installed through Operator Lifecycle Manager (OLM) are updated to their latest version in their latest channel. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See xref:../../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators] for more information.
27
+
* Have a recent xref:../../backup_and_restore/application_backup_and_restore/installing/oadp-backup-restore-csi-snapshots.adoc[Container Storage Interface (CSI) volume snapshot] in case you need to restore persistent volumes due to a pod failure.
28
+
* Your {op-system-base}7 workers are replaced with {op-system-base}8 or {op-system} workers. Red{nbsp}Hat does not support in-place {op-system-base}7 to {op-system-base}8 updates for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
29
+
* You have updated all Operators previously installed through Operator Lifecycle Manager (OLM) to a version that is compatible with your target release. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See xref:../../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators] for more information on how to check compatibility and, if necessary, update the installed Operators.
30
30
* Ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
31
31
* If your cluster uses manually maintained credentials, update the cloud provider resources for the new release. For more information, including how to determine if this is a requirement for your cluster, see xref:../../updating/preparing_for_updates/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials].
32
32
* Ensure that you address all `Upgradeable=False` conditions so the cluster allows an update to the next minor version. An alert displays at the top of the *Cluster Settings* page when you have one or more cluster Operators that cannot be updated. You can still update to the next available patch update for the minor release you are currently on.
@@ -35,7 +35,7 @@ See xref:../../authentication/using-rbac.adoc#using-rbac[Using RBAC to define an
35
35
36
36
[IMPORTANT]
37
37
====
38
-
* When an update is failing to complete, the Cluster Version Operator (CVO) reports the status of any blocking components while attempting to reconcile the update. Rolling your cluster back to a previous version is not supported. If your update is failing to complete, contact RedHat support.
38
+
* When an update is failing to complete, the Cluster Version Operator (CVO) reports the status of any blocking components while attempting to reconcile the update. Rolling your cluster back to a previous version is not supported. If your update is failing to complete, contact Red{nbsp}Hat support.
39
39
* Using the `unsupportedConfigOverrides` section to modify the configuration of an Operator is unsupported and might block cluster updates. You must remove this setting before you can update your cluster.
0 commit comments