From 4d758cab72495f2a95da974b369300ee1c74b6c5 Mon Sep 17 00:00:00 2001 From: Sebastian Kopacz Date: Wed, 18 Feb 2026 09:43:47 -0500 Subject: [PATCH] OSDOCS-17076: Updates CQA pt 2 --- ...nderstanding-update-channels-choosing.adoc | 21 +++++ ...nderstanding-update-channels-overview.adoc | 41 ++++++++ ...erstanding-update-channels-restricted.adoc | 8 ++ ...derstanding-update-channels-switching.adoc | 25 +++++ modules/understanding-update-channels.adoc | 94 ++----------------- ...understanding-update-recs-conditional.adoc | 12 +++ modules/understanding-update-recs.adoc | 22 +++++ modules/update-duration-cvo.adoc | 5 +- ...duration-estimate-cluster-update-time.adoc | 17 ++-- modules/update-duration-example.adoc | 7 +- modules/update-duration-factors.adoc | 3 + modules/update-duration-mco.adoc | 7 +- modules/update-duration-phases.adoc | 11 +++ .../intro-to-updates.adoc | 2 +- ...derstanding-openshift-update-duration.adoc | 16 +--- ...understanding-update-channels-release.adoc | 47 +++------- 16 files changed, 190 insertions(+), 148 deletions(-) create mode 100644 modules/understanding-update-channels-choosing.adoc create mode 100644 modules/understanding-update-channels-overview.adoc create mode 100644 modules/understanding-update-channels-restricted.adoc create mode 100644 modules/understanding-update-channels-switching.adoc create mode 100644 modules/understanding-update-recs-conditional.adoc create mode 100644 modules/understanding-update-recs.adoc create mode 100644 modules/update-duration-phases.adoc diff --git a/modules/understanding-update-channels-choosing.adoc b/modules/understanding-update-channels-choosing.adoc new file mode 100644 index 000000000000..3816d19b781c --- /dev/null +++ b/modules/understanding-update-channels-choosing.adoc @@ -0,0 +1,21 @@ +:_mod-docs-content-type: CONCEPT +[id="fast-stable-channel-strategies_{context}"] += Choosing the correct channel for your cluster + +[role="_abstract"] +Choosing the appropriate update channel for your cluster involves two decisions. + +First, select the minor version you want for your cluster update. Selecting a channel which matches your current version ensures that you only apply z-stream updates and do not receive feature updates. Selecting an available channel which has a version greater than your current version will ensure that after one or more updates your cluster will have updated to that version. Your cluster will only be offered channels which match its current version, the next version, or the next EUS version. + +[NOTE] +==== +Due to the complexity involved in planning updates between versions many minors apart, channels that assist in planning updates beyond a single Control Plane Only update are not offered. +==== + +Second, you should choose your desired rollout strategy. You may choose to update as soon as Red{nbsp}Hat declares a release GA by selecting from fast channels or you may want to wait for Red{nbsp}Hat to promote releases to the stable channel. Update recommendations offered in the `fast-{product-version}` and `stable-{product-version}` are both fully supported and benefit equally from ongoing data analysis. The promotion delay before promoting a release to the stable channel represents the only difference between the two channels. Updates to the latest z-streams are generally promoted to the stable channel within a week or two, however the delay when initially rolling out updates to the latest minor is much longer, generally 45-90 days. Please consider the promotion delay when choosing your desired channel, as waiting for promotion to the stable channel may affect your scheduling plans. + +Additionally, there are several factors which may lead an organization to move clusters to the fast channel either permanently or temporarily including the following: + +* The desire to apply a specific fix known to affect your environment without delay. +* Application of CVE fixes without delay. CVE fixes may introduce regressions, so promotion delays still apply to z-streams with CVE fixes. +* Internal testing processes. If it takes your organization several weeks to qualify releases it is best test concurrently with our promotion process rather than waiting. This also assures that any telemetry signal provided to Red{nbsp}Hat is a factored into our rollout, so issues relevant to you can be fixed faster. \ No newline at end of file diff --git a/modules/understanding-update-channels-overview.adoc b/modules/understanding-update-channels-overview.adoc new file mode 100644 index 000000000000..5da8be458327 --- /dev/null +++ b/modules/understanding-update-channels-overview.adoc @@ -0,0 +1,41 @@ +:_mod-docs-content-type: REFERENCE +[id="understanding-update-channels-overview_{context}"] += Overview of update channels + +[role="_abstract"] +Update channels correspond to a minor version of {product-title}. The version number in the channel represents the target minor version that the cluster will eventually be updated to, even if it is higher than the cluster's current minor version. + +For instance, {product-title} 4.10 update channels provide the following recommendations: + +* Updates within 4.10. +* Updates within 4.9. +* Updates from 4.9 to 4.10, allowing all 4.9 clusters to eventually update to 4.10, even if they do not immediately meet the minimum z-stream version requirements. +* `eus-4.10` only: updates within 4.8. +* `eus-4.10` only: updates from 4.8 to 4.9 to 4.10, allowing all 4.8 clusters to eventually update to 4.10. + +4.10 update channels do not recommend updates to 4.11 or later releases. This strategy ensures that administrators must explicitly decide to update to the next minor version of {product-title}. + +Update channels control only release selection and do not impact the version of the cluster that you install. The `openshift-install` binary file for a specific version of {product-title} always installs that version. + +ifndef::openshift-origin[] +{product-title} {product-version} offers the following update channels: + +* `stable-{product-version}` +* `eus-4.y` (only offered for EUS versions and meant to facilitate updates between EUS versions) +* `fast-{product-version}` +* `candidate-{product-version}` + +If you do not want the Cluster Version Operator to fetch available updates from the update recommendation service, you can use the `oc adm upgrade channel` command in the OpenShift CLI to configure an empty channel. This configuration can be helpful if, for example, a cluster has restricted network access and there is no local, reachable update recommendation service. + +[WARNING] +==== +Red{nbsp}Hat recommends updating only to versions suggested by OpenShift Update Service. For a minor version update, versions must be contiguous. Red{nbsp}Hat does not test updates to noncontiguous versions and cannot guarantee compatibility with earlier versions. +==== + +endif::openshift-origin[] +ifdef::openshift-origin[] +{product-title} {product-version} offers the following update channel: + +* `stable-4` + +endif::openshift-origin[] \ No newline at end of file diff --git a/modules/understanding-update-channels-restricted.adoc b/modules/understanding-update-channels-restricted.adoc new file mode 100644 index 000000000000..5432db0b5f9d --- /dev/null +++ b/modules/understanding-update-channels-restricted.adoc @@ -0,0 +1,8 @@ +:_mod-docs-content-type: CONCEPT +[id="restricted-network-clusters_{context}"] += Restricted network clusters + +[role="_abstract"] +If you manage the container images for your {product-title} clusters yourself, you must consult the Red{nbsp}Hat errata that is associated with product releases and note any comments that impact updates. + +During an update, the user interface might warn you about switching between these versions, so you must ensure that you selected an appropriate version before you bypass those warnings. \ No newline at end of file diff --git a/modules/understanding-update-channels-switching.adoc b/modules/understanding-update-channels-switching.adoc new file mode 100644 index 000000000000..7be78e22984f --- /dev/null +++ b/modules/understanding-update-channels-switching.adoc @@ -0,0 +1,25 @@ +:_mod-docs-content-type: CONCEPT +[id="switching-between-channels_{context}"] += Switching between channels + +[role="_abstract"] +You can switch your cluster's update channel through the web console or the CLI, in order to access different update recommendations for your cluster. + +You can switch the channel from the CLI by running the following command: + +[source,terminal] +---- +$ oc adm upgrade channel +---- + +The web console will display an alert if you switch to a channel that does not include the current release. The web console does not recommend any updates while on a channel without the current release. You can return to the original channel at any point, however. + +Changing your channel might impact the supportability of your cluster. The following conditions might apply: + +* Your cluster is still supported if you change from the `stable-{product-version}` channel to the `fast-{product-version}` channel. + +* You can switch to the `candidate-{product-version}` channel at any time, but some releases for this channel might be unsupported. + +* You can switch from the `candidate-{product-version}` channel to the `fast-{product-version}` channel if your current release is a general availability release. + +* You can always switch from the `fast-{product-version}` channel to the `stable-{product-version}` channel. There is a possible delay of up to a day for the release to be promoted to `stable-{product-version}` if the current release was recently promoted. \ No newline at end of file diff --git a/modules/understanding-update-channels.adoc b/modules/understanding-update-channels.adoc index 596932c4323e..e03daa7ed909 100644 --- a/modules/understanding-update-channels.adoc +++ b/modules/understanding-update-channels.adoc @@ -7,13 +7,18 @@ [id="understanding-update-channels_{context}"] = Update channels +[role="_abstract"] +{product-title} offers several update channels for you to choose from, depending on your desired update strategy. + ifndef::openshift-origin[] [id="fast-version-channel_{context}"] == fast-{product-version} channel -The `fast-{product-version}` channel is updated with new versions of {product-title} {product-version} as soon as Red Hat declares the version as a general availability (GA) release. As such, these releases are fully supported and purposed to be used in production environments. + +The `fast-{product-version}` channel is updated with new versions of {product-title} {product-version} as soon as Red{nbsp}Hat declares the version as a general availability (GA) release. As such, these releases are fully supported and purposed to be used in production environments. [id="stable-version-channel_{context}"] == stable-{product-version} channel + While the `fast-{product-version}` channel contains releases as soon as their errata are published, releases are added to the `stable-{product-version}` channel after a delay. During this delay, data is collected from multiple sources and analyzed for indications of product regressions. Once a significant number of data points have been collected, these releases are added to the stable channel. [NOTE] @@ -38,7 +43,7 @@ Both standard and non-EUS subscribers can access all EUS repositories and necess The `candidate-{product-version}` channel offers unsupported early access to releases as soon as they are built. Releases present only in candidate channels may not contain the full feature set of eventual GA releases or features may be removed prior to GA. Additionally, these releases have not been subject to full -Red Hat Quality Assurance and may not offer update paths to later GA releases. Given these caveats, the candidate channel is only suitable for testing purposes +Red{nbsp}Hat Quality Assurance and may not offer update paths to later GA releases. Given these caveats, the candidate channel is only suitable for testing purposes where destroying and recreating a cluster is acceptable. endif::openshift-origin[] @@ -47,88 +52,3 @@ ifdef::openshift-origin[] == stable-4 channel Releases are added to the `stable-4` channel after passing all tests and stable-4 is the only supported channel. endif::openshift-origin[] - - -ifndef::openshift-origin[] -[id="upgrade-version-paths_{context}"] -== Update recommendations in the channel - -{product-title} maintains an update recommendation service that knows your installed {product-title} version and the path to take within the channel to get you to the next release. Update paths are also limited to versions relevant to your currently selected channel and its promotion characteristics. - -You can imagine seeing the following releases in your channel: - -* {product-version}.0 -* {product-version}.1 -* {product-version}.3 -* {product-version}.4 - -The service recommends only updates that have been tested and have no known serious regressions. For example, if your cluster is on {product-version}.1 and {product-title} suggests {product-version}.4, then it is recommended to update from {product-version}.1 to {product-version}.4. - -[IMPORTANT] -==== -Do not rely on consecutive patch numbers. In this example, {product-version}.2 is not and never was available in the channel, therefore updates to {product-version}.2 are not recommended or supported. -==== - -[id="conditional-updates-overview_{context}"] -== Update recommendations and Conditional Updates -Red Hat monitors newly released versions and update paths associated with those versions before and after they are added to supported channels. - -If Red Hat removes update recommendations from any supported release, a superseding update recommendation will be provided to a future version that corrects the regression. There may however be a delay while the defect is corrected, tested, and promoted to your selected channel. - -Beginning in {product-title} 4.10, when update risks are confirmed, they are declared as Conditional Update risks for the relevant updates. Each known risk may apply to all clusters or only clusters matching certain conditions. Some examples include having the `Platform` set to `None` or the CNI provider set to `OpenShiftSDN`. The Cluster Version Operator (CVO) continually evaluates known risks against the current cluster state. If no risks match, the update is recommended. If the risk matches, those update paths are labeled as _updates with known issues_, and a reference link to the known issues is provided. The reference link helps the cluster admin decide if they want to accept the risk and continue to update their cluster. - -When Red Hat chooses to declare Conditional Update risks, that action is taken in all relevant channels simultaneously. Declaration of a Conditional Update risk may happen either before or after the update has been promoted to supported channels. - -ifndef::openshift-origin[] - -[id="fast-stable-channel-strategies_{context}"] -== Choosing the correct channel for your cluster - -Choosing the appropriate channel involves two decisions. - -First, select the minor version you want for your cluster update. Selecting a channel which matches your current version ensures that you only apply z-stream updates and do not receive feature updates. Selecting an available channel which has a version greater than your current version will ensure that after one or more updates your cluster will have updated to that version. Your cluster will only be offered channels which match its current version, the next version, or the next EUS version. - -[NOTE] -==== -Due to the complexity involved in planning updates between versions many minors apart, channels that assist in planning updates beyond a single Control Plane Only update are not offered. -==== - -Second, you should choose your desired rollout strategy. You may choose to update as soon as Red Hat declares a release GA by selecting from fast channels or you may want to wait for Red Hat to promote releases to the stable channel. Update recommendations offered in the `fast-{product-version}` and `stable-{product-version}` are both fully supported and benefit equally from ongoing data analysis. The promotion delay before promoting a release to the stable channel represents the only difference between the two channels. Updates to the latest z-streams are generally promoted to the stable channel within a week or two, however the delay when initially rolling out updates to the latest minor is much longer, generally 45-90 days. Please consider the promotion delay when choosing your desired channel, as waiting for promotion to the stable channel may affect your scheduling plans. - -Additionally, there are several factors which may lead an organization to move clusters to the fast channel either permanently or temporarily including: - -* The desire to apply a specific fix known to affect your environment without delay. -* Application of CVE fixes without delay. CVE fixes may introduce regressions, so promotion delays still apply to z-streams with CVE fixes. -* Internal testing processes. If it takes your organization several weeks to qualify releases it is best test concurrently with our promotion process rather than waiting. This also assures that any telemetry signal provided to Red Hat is a factored into our rollout, so issues relevant to you can be fixed faster. - -endif::openshift-origin[] - -[id="restricted-network-clusters_{context}"] -== Restricted network clusters - -If you manage the container images for your {product-title} clusters yourself, you must consult the Red Hat errata that is associated with product releases and note any comments that impact updates. During an update, the user interface might warn you about switching between these versions, so you must ensure that you selected an appropriate version before you bypass those warnings. - -ifndef::openshift-origin[] - -[id="switching-between-channels_{context}"] -== Switching between channels - -A channel can be switched from the web console or through the `adm upgrade channel` command: - -[source,terminal] ----- -$ oc adm upgrade channel ----- - -The web console will display an alert if you switch to a channel that does not include the current release. The web console does not recommend any updates while on a channel without the current release. You can return to the original channel at any point, however. - -Changing your channel might impact the supportability of your cluster. The following conditions might apply: - -* Your cluster is still supported if you change from the `stable-{product-version}` channel to the `fast-{product-version}` channel. - -* You can switch to the `candidate-{product-version}` channel at any time, but some releases for this channel might be unsupported. - -* You can switch from the `candidate-{product-version}` channel to the `fast-{product-version}` channel if your current release is a general availability release. - -* You can always switch from the `fast-{product-version}` channel to the `stable-{product-version}` channel. There is a possible delay of up to a day for the release to be promoted to `stable-{product-version}` if the current release was recently promoted. -endif::openshift-origin[] diff --git a/modules/understanding-update-recs-conditional.adoc b/modules/understanding-update-recs-conditional.adoc new file mode 100644 index 000000000000..e5fd860f3f69 --- /dev/null +++ b/modules/understanding-update-recs-conditional.adoc @@ -0,0 +1,12 @@ +:_mod-docs-content-type: CONCEPT +[id="conditional-updates-overview_{context}"] += Update recommendations and Conditional Updates + +[role="_abstract"] +Red{nbsp}Hat monitors newly released versions and update paths associated with those versions before and after they are added to supported channels. + +If Red Hat removes update recommendations from any supported release, a superseding update recommendation will be provided to a future version that corrects the regression. There may however be a delay while the defect is corrected, tested, and promoted to your selected channel. + +Beginning in {product-title} 4.10, when update risks are confirmed, they are declared as Conditional Update risks for the relevant updates. Each known risk may apply to all clusters or only clusters matching certain conditions. Some examples include having the `Platform` set to `None` or the CNI provider set to `OpenShiftSDN`. The Cluster Version Operator (CVO) continually evaluates known risks against the current cluster state. If no risks match, the update is recommended. If the risk matches, those update paths are labeled as _updates with known issues_, and a reference link to the known issues is provided. The reference link helps the cluster admin decide if they want to accept the risk and continue to update their cluster. + +When Red{nbsp}Hat chooses to declare Conditional Update risks, that action is taken in all relevant channels simultaneously. Declaration of a Conditional Update risk may happen either before or after the update has been promoted to supported channels. \ No newline at end of file diff --git a/modules/understanding-update-recs.adoc b/modules/understanding-update-recs.adoc new file mode 100644 index 000000000000..de9a434e266c --- /dev/null +++ b/modules/understanding-update-recs.adoc @@ -0,0 +1,22 @@ +:_mod-docs-content-type: CONCEPT +[id="upgrade-version-paths_{context}"] += Update recommendations in the channel + +[role="_abstract"] +{product-title} maintains an update recommendation service that knows your installed {product-title} version and the path to take within the channel to get you to the next release. + +Update paths are also limited to versions relevant to your currently selected channel and its promotion characteristics. + +You can imagine seeing the following releases in your channel: + +* {product-version}.0 +* {product-version}.1 +* {product-version}.3 +* {product-version}.4 + +The service recommends only updates that have been tested and have no known serious regressions. For example, if your cluster is on {product-version}.1 and {product-title} suggests {product-version}.4, then it is recommended to update from {product-version}.1 to {product-version}.4. + +[IMPORTANT] +==== +Do not rely on consecutive patch numbers. In this example, {product-version}.2 is not and never was available in the channel, therefore updates to {product-version}.2 are not recommended or supported. +==== diff --git a/modules/update-duration-cvo.adoc b/modules/update-duration-cvo.adoc index 781f4838e184..400ffbf71407 100644 --- a/modules/update-duration-cvo.adoc +++ b/modules/update-duration-cvo.adoc @@ -6,7 +6,10 @@ [id="cluster-version-operator_{context}"] = Cluster Version Operator target update payload deployment -The Cluster Version Operator (CVO) retrieves the target update release image and applies to the cluster. All components which run as pods are updated during this phase, whereas the host components are updated by the Machine Config Operator (MCO). This process might take 60 to 120 minutes. +[role="_abstract"] +In the first phase of the update, the Cluster Version Operator (CVO) retrieves the target update release image and applies to the cluster. + +All components which run as pods are updated during this phase, whereas the host components are updated by the Machine Config Operator (MCO). This process might take 60 to 120 minutes. [NOTE] ==== diff --git a/modules/update-duration-estimate-cluster-update-time.adoc b/modules/update-duration-estimate-cluster-update-time.adoc index 4f3d3dff551b..7c75ad82a7a1 100644 --- a/modules/update-duration-estimate-cluster-update-time.adoc +++ b/modules/update-duration-estimate-cluster-update-time.adoc @@ -6,8 +6,12 @@ [id="estimating-cluster-update-time_{context}"] = Estimating cluster update time -Historical update duration of similar clusters provides you the best estimate for the future cluster updates. However, if the historical data is not available, you can use the following convention to estimate your cluster update time: +[role="_abstract"] +Historical update duration of similar clusters provides you the best estimate for the future cluster updates. If you do not have historical data, you can calculate an estimate of the update duration. +You can use the following convention to estimate your cluster update time: + +[source,text] ---- Cluster update time = CVO target update payload deployment time + (# node update iterations x MCO node update time) ---- @@ -19,23 +23,24 @@ A node update iteration consists of one or more nodes updated in parallel. The c The default setting for `maxUnavailable` is `1` for all the machine config pools in {product-title}. It is recommended to not change this value and update one control plane node at a time. Do not change this value to `3` for the control plane pool. ==== -For example, to estimate the update time, consider an {product-title} cluster with three control plane nodes and six compute nodes and each host takes about 5 minutes to reboot. +For example, to estimate the update time, consider an {product-title} cluster with three control plane nodes and six compute nodes, where each host takes about 5 minutes to reboot. [NOTE] ==== The time it takes to reboot a particular node varies significantly. In cloud instances, the reboot might take about 1 to 2 minutes, whereas in physical bare metal hosts the reboot might take more than 15 minutes. ==== -.Scenario-1 -When you set `maxUnavailable` to `1` for both the control plane and compute nodes Machine Config Pool (MCP), then all the six compute nodes will update one after another in each iteration: +In a scenario where you set `maxUnavailable` to `1` for both the control plane and compute nodes Machine Config Pool (MCP), then all the six compute nodes will update one after another in each iteration: + +[source,text] ---- Cluster update time = 60 + (6 x 5) = 90 minutes ---- -.Scenario-2 -When you set `maxUnavailable` to `2` for the compute node MCP, then two compute nodes will update in parallel in each iteration. Therefore it takes total three iterations to update all the nodes. +In a scenario where you set `maxUnavailable` to `2` for the compute node MCP, then two compute nodes will update in parallel in each iteration. Therefore it takes total three iterations to update all the nodes. +[source,text] ---- Cluster update time = 60 + (3 x 5) = 75 minutes ---- diff --git a/modules/update-duration-example.adoc b/modules/update-duration-example.adoc index 3a8836a046ae..1adc2cb3dce1 100644 --- a/modules/update-duration-example.adoc +++ b/modules/update-duration-example.adoc @@ -6,6 +6,9 @@ [id="update-duration-example_{context}"] = Example update duration of cluster Operators +[role="_abstract"] +You can review an example of the update duration for cluster Operators to better understand the factors that affect the duration of the update. + image::update-duration.png[A diagram displaying the periods during which cluster Operators update themselves during an OCP update] The previous diagram shows an example of the time that cluster Operators might take to update to their new versions. @@ -27,11 +30,11 @@ In the case of this Operator, update speed is sacrificed to help prevent and lim Another characteristic that affects the update duration of an Operator is whether the Operator utilizes DaemonSets. The Network and DNS Operators utilize full-cluster DaemonSets, which can take time to roll out their version changes, and this is one of several reasons why these Operators might take longer to update themselves. -The update duration for some Operators is heavily dependent on characteristics of the cluster itself. For instance, the Machine Config Operator update applies machine configuration changes to each node in the cluster. A cluster with many nodes has a longer update duration for the Machine Config Operator compared to a cluster with fewer nodes. +Additionally, the update duration for some Operators is heavily dependent on characteristics of the cluster itself. For example, the Machine Config Operator update applies machine configuration changes to each node in the cluster. A cluster with many nodes has a longer update duration for the Machine Config Operator compared to a cluster with fewer nodes. [NOTE] ==== Each cluster Operator is assigned a stage during which it can be updated. Operators within the same stage can update simultaneously, and Operators in a given stage cannot begin updating until all previous stages have been completed. -For more information, see "Understanding how manifests are applied during an update" in the "Additional resources" section. +For more information, see "Understanding how manifests are applied during an update". ==== \ No newline at end of file diff --git a/modules/update-duration-factors.adoc b/modules/update-duration-factors.adoc index a427eeb9cf5a..519329df50d9 100644 --- a/modules/update-duration-factors.adoc +++ b/modules/update-duration-factors.adoc @@ -6,6 +6,9 @@ [id="factors-affecting-update-duration_{context}"] = Factors affecting update duration +[role="_abstract"] +The duration of {product-title} updates vary for several reasons. + The following factors can affect your cluster update duration: * The reboot of compute nodes to the new machine configuration by Machine Config Operator (MCO) diff --git a/modules/update-duration-mco.adoc b/modules/update-duration-mco.adoc index 3cbe2a2f53f4..fd19756a5685 100644 --- a/modules/update-duration-mco.adoc +++ b/modules/update-duration-mco.adoc @@ -6,7 +6,10 @@ [id="machine-config-operator-node-updates_{context}"] = Machine Config Operator node updates -The Machine Config Operator (MCO) applies a new machine configuration to each control plane and compute node. During this process, the MCO performs the following sequential actions on each node of the cluster: +[role="_abstract"] +In the second phase of the update, the Machine Config Operator (MCO) applies a new machine configuration to each control plane and compute node. + +During this process, the MCO performs the following sequential actions on each node of the cluster: . Cordon and drain all the nodes . Update the operating system (OS) @@ -51,4 +54,4 @@ ip-10-0-207-224.us-east-2.compute.internal Ready worker + If the status of the node is `NotReady` or `SchedulingDisabled`, then the node is not available and this impacts the update duration. + -You can check the status of nodes from the *Administrator* perspective in the web console by expanding **Compute** -> **Nodes**. +You can also check the status of nodes from the *Administrator* perspective in the web console by expanding **Compute** -> **Nodes**. diff --git a/modules/update-duration-phases.adoc b/modules/update-duration-phases.adoc new file mode 100644 index 000000000000..5d3aec9533e0 --- /dev/null +++ b/modules/update-duration-phases.adoc @@ -0,0 +1,11 @@ +:_mod-docs-content-type: REFERENCE +[id="cluster-update-phases_{context}"] += Cluster update phases + +[role="_abstract"] +{product-title} updates are done in multiple phases. + +The cluster update happens in the following two phases: + +* Cluster Version Operator (CVO) target update payload deployment +* Machine Config Operator (MCO) node updates \ No newline at end of file diff --git a/updating/understanding_updates/intro-to-updates.adoc b/updating/understanding_updates/intro-to-updates.adoc index c277008b127c..5e7547e93e5f 100644 --- a/updating/understanding_updates/intro-to-updates.adoc +++ b/updating/understanding_updates/intro-to-updates.adoc @@ -48,6 +48,6 @@ ifdef::openshift-enterprise[] [id="{context}-additional-resources"] [role="_additional-resources"] == Additional resources -* xref:../../updating/understanding_updates/how-updates-work.adoc#how-updates-work[How cluster updates work]. +* xref:../../updating/understanding_updates/how-updates-work.adoc#how-updates-work[How cluster updates work] endif::openshift-enterprise[] \ No newline at end of file diff --git a/updating/understanding_updates/understanding-openshift-update-duration.adoc b/updating/understanding_updates/understanding-openshift-update-duration.adoc index a5af24a128a2..7d9cc866a6ee 100644 --- a/updating/understanding_updates/understanding-openshift-update-duration.adoc +++ b/updating/understanding_updates/understanding-openshift-update-duration.adoc @@ -6,23 +6,13 @@ include::_attributes/common-attributes.adoc[] toc::[] -//// -WARNING: This assembly has been moved into a subdirectory for 4.14+. Changes to this assembly for earlier versions should be done in separate PRs based off of their respective version branches. Otherwise, your cherry picks may fail. - -To do: Remove this comment once 4.13 docs are EOL. -//// - -{product-title} update duration varies based on the deployment topology. This page helps you understand the factors that affect update duration and estimate how long the cluster update takes in your environment. +[role="_abstract"] +{product-title} update duration varies based on the deployment topology. You can understand the factors that affect update duration and use them to estimate how long the cluster update takes in your environment. // Factors affecting update duration include::modules/update-duration-factors.adoc[leveloffset=+1] -[id="cluster-update-phases"] -== Cluster update phases -In {product-title}, the cluster update happens in two phases: - -* Cluster Version Operator (CVO) target update payload deployment -* Machine Config Operator (MCO) node updates +include::modules/update-duration-phases.adoc[leveloffset=+1] // Cluster Version Operator target update payload deployment include::modules/update-duration-cvo.adoc[leveloffset=+2] diff --git a/updating/understanding_updates/understanding-update-channels-release.adoc b/updating/understanding_updates/understanding-update-channels-release.adoc index a29a9193a988..d71c353412bd 100644 --- a/updating/understanding_updates/understanding-update-channels-release.adoc +++ b/updating/understanding_updates/understanding-update-channels-release.adoc @@ -6,53 +6,28 @@ include::_attributes/common-attributes.adoc[] toc::[] -//// -WARNING: This assembly has been moved into a subdirectory for 4.14+. Changes to this assembly for earlier versions should be done in separate PRs based off of their respective version branches. Otherwise, your cherry picks may fail. +[role="_abstract"] +Update channels are the mechanism by which users declare the {product-title} minor version they intend to update their clusters to. They also allow users to choose the timing and level of support their updates will have through the `fast`, `stable`, `candidate`, and `eus` channel options. -To do: Remove this comment once 4.13 docs are EOL. -//// +The Cluster Version Operator uses an update graph based on the channel declaration, along with other conditional information, to provide a list of recommended and conditional updates available to the cluster. -Update channels are the mechanism by which users declare the {product-title} minor version they intend to update their clusters to. They also allow users to choose the timing and level of support their updates will have through the `fast`, `stable`, `candidate`, and `eus` channel options. The Cluster Version Operator uses an update graph based on the channel declaration, along with other conditional information, to provide a list of recommended and conditional updates available to the cluster. +include::modules/understanding-update-channels-overview.adoc[leveloffset=+1] -Update channels correspond to a minor version of {product-title}. The version number in the channel represents the target minor version that the cluster will eventually be updated to, even if it is higher than the cluster's current minor version. - -For instance, {product-title} 4.10 update channels provide the following recommendations: - -* Updates within 4.10. -* Updates within 4.9. -* Updates from 4.9 to 4.10, allowing all 4.9 clusters to eventually update to 4.10, even if they do not immediately meet the minimum z-stream version requirements. -* `eus-4.10` only: updates within 4.8. -* `eus-4.10` only: updates from 4.8 to 4.9 to 4.10, allowing all 4.8 clusters to eventually update to 4.10. - -4.10 update channels do not recommend updates to 4.11 or later releases. This strategy ensures that administrators must explicitly decide to update to the next minor version of {product-title}. +// Update channels +include::modules/understanding-update-channels.adoc[leveloffset=+1] -Update channels control only release selection and do not impact the version of the cluster that you install. The `openshift-install` binary file for a specific version of {product-title} always installs that version. +include::modules/understanding-update-channels-restricted.adoc[leveloffset=+1] ifndef::openshift-origin[] -{product-title} {product-version} offers the following update channels: +include::modules/understanding-update-recs.adoc[leveloffset=+1] -* `stable-{product-version}` -* `eus-4.y` (only offered for EUS versions and meant to facilitate updates between EUS versions) -* `fast-{product-version}` -* `candidate-{product-version}` +include::modules/understanding-update-recs-conditional.adoc[leveloffset=+1] -If you do not want the Cluster Version Operator to fetch available updates from the update recommendation service, you can use the `oc adm upgrade channel` command in the OpenShift CLI to configure an empty channel. This configuration can be helpful if, for example, a cluster has restricted network access and there is no local, reachable update recommendation service. +include::modules/understanding-update-channels-choosing.adoc[leveloffset=+1] -[WARNING] -==== -Red Hat recommends updating to versions suggested by OpenShift Update Service only. For a minor version update, versions must be contiguous. Red Hat does not test updates to noncontiguous versions and cannot guarantee compatibility with earlier versions. -==== +include::modules/understanding-update-channels-switching.adoc[leveloffset=+1] endif::openshift-origin[] -ifdef::openshift-origin[] -{product-title} {product-version} offers the following update channel: - -* `stable-4` - -endif::openshift-origin[] - -// Update channels -include::modules/understanding-update-channels.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources