From 68cc17d8f092e4f6faa00146e7a375456b421b1d Mon Sep 17 00:00:00 2001 From: Samantha Gidlow Date: Thu, 9 Dec 2021 18:33:00 -0500 Subject: [PATCH] [enterprise-4.6] OTA-472: Adding a chapter and reorganizing --- _javascripts/page-loader.js | 4 +- _topic_maps/_topic_map.yml | 10 ++-- installing/install_config/customizations.adoc | 2 +- .../ipi-install-installation-workflow.adoc | 2 +- installing/validating-an-installation.adoc | 4 +- .../planning-migration-3-4.adoc | 2 +- modules/understanding-upgrade-channels.adoc | 55 +++++++------------ modules/unmanaged-operators.adoc | 2 +- modules/update-service-overview.adoc | 4 +- modules/update-upgrading-web.adoc | 28 +--------- release_notes/ocp-4-6-release-notes.adoc | 4 +- .../security-hosts-vms.adoc | 2 +- .../about-remote-health-monitoring.adoc | 8 +-- updating/installing-update-service.adoc | 4 +- ...nderstanding-upgrade-channels-release.adoc | 30 ++++++++++ updating/updating-cluster-cli.adoc | 5 +- updating/updating-cluster-rhel-compute.adoc | 3 - ...doc => updating-cluster-within-minor.adoc} | 11 ++-- welcome/index.adoc | 2 +- welcome/learn_more_about_openshift.adoc | 2 +- whats_new/new-features.adoc | 2 +- 21 files changed, 83 insertions(+), 103 deletions(-) create mode 100644 updating/understanding-upgrade-channels-release.adoc rename updating/{updating-cluster-between-minor.adoc => updating-cluster-within-minor.adoc} (88%) diff --git a/_javascripts/page-loader.js b/_javascripts/page-loader.js index 6c8f16e1e30e..bf98ad0059a5 100644 --- a/_javascripts/page-loader.js +++ b/_javascripts/page-loader.js @@ -84,8 +84,8 @@ function selectVersion(currentVersion) { // main file to edit is the file path after the version to the html at // the end. - // Example: https://docs.openshift.com/container-platform/4.4/updating/updating-cluster-between-minor.html - // file path is updating/updating-cluster-between-minor.adoc + // Example: https://docs.openshift.com/container-platform/4.4/updating/updating-cluster-within-minor.html + // file path is updating/updating-cluster-within-minor.adoc mainFileToEdit = window.location.pathname.substring( diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index 086c7b5e6529..8a86d0521fd0 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -312,11 +312,11 @@ Topics: File: understanding-the-update-service - Name: Installing and configuring the OpenShift Update Service File: installing-update-service -- Name: Updating a cluster between minor versions - File: updating-cluster-between-minor -- Name: Updating a cluster within a minor version from the web console - File: updating-cluster -- Name: Updating a cluster within a minor version by using the CLI +- Name: Understanding upgrade channels + File: understanding-upgrade-channels-release +- Name: Updating a cluster within a minor version using the web console + File: updating-cluster-within-minor +- Name: Updating a cluster within a minor version using the CLI File: updating-cluster-cli - Name: Updating a cluster that includes RHEL compute machines File: updating-cluster-rhel-compute diff --git a/installing/install_config/customizations.adoc b/installing/install_config/customizations.adoc index df63e7395e45..10fe2f14e1fc 100644 --- a/installing/install_config/customizations.adoc +++ b/installing/install_config/customizations.adoc @@ -135,7 +135,7 @@ You use these resources to retrieve information about the cluster. Do not edit t |`version` |In {product-title} {product-version}, you must not customize the `ClusterVersion` resource for production clusters. Instead, follow the process to -xref:../../updating/updating-cluster.adoc#updating-cluster[update a cluster]. +xref:../../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[update a cluster]. |`dns.config.openshift.io` |`cluster` diff --git a/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc b/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc index 11432223dd39..ff10798bc127 100644 --- a/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc +++ b/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc @@ -13,7 +13,7 @@ include::modules/ipi-install-retrieving-the-openshift-installer.adoc[leveloffset .Additional resources -* See xref:../../updating/updating-cluster-between-minor.adoc#understanding-upgrade-channels_updating-cluster-between-minor[{product-title} upgrade channels and releases] for an explanation of the different release channels. +* See xref:../../updating/understanding-upgrade-channels-release.adoc#understanding-upgrade-channels_understanding-upgrade-channels-releases[{product-title} upgrade channels and releases] for an explanation of the different release channels. include::modules/ipi-install-extracting-the-openshift-installer.adoc[leveloffset=+1] diff --git a/installing/validating-an-installation.adoc b/installing/validating-an-installation.adoc index 3dcdb9fc209b..5fd1ed0ad6fc 100644 --- a/installing/validating-an-installation.adoc +++ b/installing/validating-an-installation.adoc @@ -22,9 +22,9 @@ include::modules/getting-cluster-version-status-and-update-details.adoc[leveloff * See xref:../support/troubleshooting/troubleshooting-operator-issues.adoc#troubleshooting-operator-issues[Troubleshooting Operator issues] for information about investigating issues with Operators. -* See xref:../updating/updating-cluster-between-minor.adoc#updating-cluster-between-minor[Updating a cluster between minor versions] for more information on updating your cluster. +* See xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[Updating a cluster between minor versions] for more information on updating your cluster. -* See xref:../updating/updating-cluster-between-minor.adoc#understanding-upgrade-channels_updating-cluster-between-minor[OpenShift Container Platform upgrade channels and releases] for an overview about upgrade release channels. +* See xref:../updating/understanding-upgrade-channels-release.adoc#understanding-upgrade-channels_understanding-upgrade-channels-releases[OpenShift Container Platform upgrade channels and releases] for an overview about upgrade release channels. //Querying the status of the cluster nodes by using the CLI include::modules/querying-the-status-of-cluster-nodes-using-the-cli.adoc[leveloffset=+1] diff --git a/migrating_from_ocp_3_to_4/planning-migration-3-4.adoc b/migrating_from_ocp_3_to_4/planning-migration-3-4.adoc index e7761a4da383..372f637f758b 100644 --- a/migrating_from_ocp_3_to_4/planning-migration-3-4.adoc +++ b/migrating_from_ocp_3_to_4/planning-migration-3-4.adoc @@ -66,7 +66,7 @@ For more information, see xref:../architecture/architecture-installation.adoc#in In {product-title} 3.11, you upgraded your cluster by running Ansible playbooks. In {product-title} {product-version}, the cluster manages its own updates, including updates to {op-system-first} on cluster nodes. You can easily upgrade your cluster by using the web console or by using the `oc adm upgrade` command from the OpenShift CLI and the Operators will automatically upgrade themselves. If your {product-title} {product-version} cluster has {op-system-base} worker machines, then you will still need to run an Ansible playbook to upgrade those worker machines. -For more information, see xref:../updating/updating-cluster-between-minor.adoc#updating-cluster-between-minor[Updating clusters]. +For more information, see xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[Updating clusters]. [id="migration-considerations"] == Migration considerations diff --git a/modules/understanding-upgrade-channels.adoc b/modules/understanding-upgrade-channels.adoc index 8d5dcc5b1cf7..c3ae1b2266ca 100644 --- a/modules/understanding-upgrade-channels.adoc +++ b/modules/understanding-upgrade-channels.adoc @@ -1,36 +1,14 @@ // Module included in the following assemblies: // -// * updating/updating-cluster.adoc -// * updating/updating-cluster-between-minor.adoc -// * updating/updating-cluster-cli.adoc -// * updating/updating-cluster-rhel-compute.adoc +// * updating/understanding-upgrade-channels-release.adoc // * updating/updating-disconnected-cluster.adoc [id="understanding-upgrade-channels_{context}"] -= {product-title} upgrade channels and releases += Upgrade channels and release paths -In {product-title} 4.1, Red Hat introduced the concept of channels for recommending the appropriate release versions for cluster upgrades. By controlling the pace of upgrades, these upgrade channels allow you to choose an upgrade strategy. Upgrade channels are tied to a minor version of {product-title}. For instance, {product-title} 4.6 upgrade channels recommend upgrades to 4.6 and upgrades within 4.6. They also recommend upgrades within 4.5 and from 4.5 to 4.6, to allow clusters on 4.5 to eventually upgrade to 4.6. They do not recommend upgrades to 4.7 or later releases. This strategy ensures that administrators explicitly decide to upgrade to the next minor version of {product-title}. +Cluster administrators can configure the upgrade channel from the web console. -Upgrade 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 upgrade channels: - -* `candidate-{product-version}` -* `fast-{product-version}` -* `stable-{product-version}` -* `eus-4.6` (only when running an even-numbered 4.y cluster release, like 4.6) - -endif::openshift-origin[] -ifdef::openshift-origin[] -{product-title} {product-version} offers the following upgrade channel: - -* `stable-4` - -endif::openshift-origin[] - -ifndef::openshift-origin[] -[discrete] +[id="candidate-version-channel_{context}"] == candidate-{product-version} channel The `candidate-{product-version}` channel contains candidate builds for a z-stream ({product-version}.z) and previous minor version releases. Release candidates contain all the features of the product but are not supported. Use release candidate versions to test feature acceptance and assist in qualifying the next version of {product-title}. A release candidate is any build that is available in the candidate channel, including ones that do not contain link:https://semver.org/spec/v2.0.0.html#spec-item-9[a pre-release version] such as `-rc` in their names. After a version is available in the candidate channel, it goes through more quality checks. If it meets the quality standard, it is promoted to the `fast-{product-version}` or `stable-{product-version}` channels. Because of this strategy, if a specific release is available in both the `candidate-{product-version}` channel and in the `fast-{product-version}` or `stable-{product-version}` channels, it is a Red Hat-supported version. The `candidate-{product-version}` channel can include release versions from which there are no recommended updates in any channel. @@ -49,23 +27,24 @@ endif::[] for more build information. ==== -[discrete] +[id="fast-version-channel_{context}"] == fast-{product-version} channel The `fast-{product-version}` channel is updated with new and previous minor versions of {product-version} as soon as Red Hat declares the given version as a general availability release. As such, these releases are fully supported, are production quality, and have performed well while available as a release candidate in the `candidate-{product-version}` channel from where they were promoted. Some time after a release appears in the `fast-{product-version}` channel, it is added to the `stable-{product-version}` channel. Releases never appear in the `stable-{product-version}` channel before they appear in the `fast-{product-version}` channel. You can use the `fast-{product-version}` channel to upgrade from a previous minor version of {product-title}. -endif::openshift-origin[] ifndef::openshift-origin[] -[discrete] + +[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 Red Hat SRE teams, Red Hat support services, and pre-production and production environments that participate in connected customer program about the stability of the release. You can use the `stable-{product-version}` channel to upgrade from a previous minor version of {product-title}. endif::openshift-origin[] ifdef::openshift-origin[] -[discrete] + +[id="stable-4-channel_{context}"] == stable-4 channel Releases are added to the `stable-4` channel after passing all tests. @@ -73,8 +52,9 @@ You can use the `stable-4` channel to upgrade from a previous minor version of { endif::openshift-origin[] ifndef::openshift-origin[] -[discrete] -== eus-4.6 channel + +[id="eus-4y-channel_{context}"] +== eus-4.y channel In addition to the stable channel, all even-numbered minor versions of {product-title} offer an link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[Extended Update Support] (EUS). The EUS 4.6 channel extends the maintenance phase for customers with Premium Subscriptions to 14 months. @@ -82,7 +62,7 @@ Although there is no difference between `stable-4.6` and `eus-4.6` channels unti endif::openshift-origin[] -[discrete] +[id="upgrade-version-paths_{context}"] == Upgrade version paths {product-title} maintains an upgrade recommendation service that understands the version of {product-title} you have installed as well as the path to take within the channel you choose to get you to the next release. @@ -112,7 +92,8 @@ The presence of an update recommendation in the `stable-4` channel at any point endif::openshift-origin[] ifndef::openshift-origin[] -[discrete] + +[id="fast-stable-channel-strategies_{context}"] == Fast and stable channel use and strategies The `fast-{product-version}` and `stable-{product-version}` channels present a choice between receiving general availability releases as soon as they are available or allowing Red Hat to control the rollout of those updates. If issues are detected during rollout or at a later time, upgrades to that version might be blocked in both the `fast-{product-version}` and `stable-{product-version}` channels, and a new version might be introduced that becomes the new preferred upgrade target. @@ -120,17 +101,19 @@ The `fast-{product-version}` and `stable-{product-version}` channels present a c Customers can improve this process by configuring pre-production systems on the `fast-{product-version}` channel, configuring production systems on the `stable-{product-version}` channel, and participating in the Red Hat connected customer program. Red Hat uses this program to observe the impact of updates on your specific hardware and software configurations. Future releases might improve or alter the pace at which updates move from the `fast-{product-version}` to the `stable-{product-version}` channel. endif::openshift-origin[] -[discrete] +[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 upgrades. During upgrade, 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[] -[discrete] + +[id="switching-between-channels_{context}"] == Switching between channels A channel can be switched from the web console or through the `patch` command: +[source,terminal] ---- $ oc patch clusterversion version --type json -p '[{"op": "add", "path": "/spec/channel", "value": "”}]' ---- diff --git a/modules/unmanaged-operators.adoc b/modules/unmanaged-operators.adoc index 95def22db4d0..ebdcbfd595fe 100644 --- a/modules/unmanaged-operators.adoc +++ b/modules/unmanaged-operators.adoc @@ -1,7 +1,7 @@ // Module included in the following assemblies: // // * architecture/architecture-installation.adoc -// * updating/updating-cluster-between-minor.adoc +// * updating/updating-cluster-within-minor.adoc [id="unmanaged-operators_{context}"] = Support policy for unmanaged Operators diff --git a/modules/update-service-overview.adoc b/modules/update-service-overview.adoc index 631e9468847e..e046d56322ce 100644 --- a/modules/update-service-overview.adoc +++ b/modules/update-service-overview.adoc @@ -2,7 +2,7 @@ // // * architecture/architecture-installation.adoc // * architecture/control-plane.adoc -// * updating/updating-cluster-between-minor.adoc +// * updating/updating-cluster-within-minor.adoc // * updating/updating-cluster-cli.adoc // * updating/updating-cluster-rhel-compute.adoc // * updating/updating-cluster.adoc @@ -39,7 +39,7 @@ Only upgrading to a newer version is supported. Reverting or rolling back your c During the upgrade process, the Machine Config Operator (MCO) applies the new configuration to your cluster machines. The MCO cordons the number of nodes as specified by the `maxUnavailable` field on the machine configuration pool and marks them as unavailable. By default, this value is set to `1`. The MCO then applies the new configuration and reboots the machine. -If you use {op-system-base-full} machines as workers, the MCO does not update the kubelet because you must update the OpenShift API on the machines first. +If you use {op-system-base-full} machines as workers, the MCO does not update the kubelet because you must update the OpenShift API on the machines first. With the specification for the new version applied to the old kubelet, the {op-system-base} machine cannot return to the `Ready` state. You cannot complete the update until the machines are available. However, the maximum number of unavailable nodes is set to ensure that normal cluster operations can continue with that number of machines out of service. diff --git a/modules/update-upgrading-web.adoc b/modules/update-upgrading-web.adoc index 4bf4f5fa9f0e..5d7700e44607 100644 --- a/modules/update-upgrading-web.adoc +++ b/modules/update-upgrading-web.adoc @@ -1,17 +1,10 @@ // Module included in the following assemblies: // // * updating/updating-cluster.adoc -// * updating/updating-cluster-between-minor.adoc +// * updating/updating-cluster-within-minor.adoc -ifeval::["{context}" == "updating-cluster"] -:within: -endif::[] -ifeval::["{context}" == "updating-cluster-between-minor"] -:between: -endif::[] ifeval::["{context}" == "updating-cluster-rhel-compute"] :rhel: -:between: endif::[] [id="update-upgrading-web_{context}"] @@ -31,14 +24,7 @@ of the Customer Portal. . From the web console, click *Administration* -> *Cluster Settings* and review the contents of the *Details* tab. -. For production clusters, ensure that the *Channel* is set to the correct channel for -ifdef::within[] -the version that you want to update to, -endif::within[] -ifdef::between[] -your current minor version, -endif::between[] -such as `stable-{product-version}`. +. For production clusters, ensure that the *Channel* is set to the correct channel for the version that you want to update to, such as `stable-{product-version}`. + [IMPORTANT] ==== @@ -49,14 +35,7 @@ cluster. ** *Select channel* indicates the cluster version that your cluster is running or is updating to. -. Select -ifdef::within[] -a version to update to, -endif::within[] -ifdef::between[] -the highest available version -endif::between[] -and click *Save*. +. Select a version to update to, and click *Save*. + The Input channel *Update Status* changes to *Update to in progress*, and @@ -68,7 +47,6 @@ for the Operators and nodes. If you are upgrading your cluster to the next minor version, like version 4.y to 4.(y+1), it is recommended to confirm your nodes are upgraded 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. ==== -ifdef::between[] . After the update completes and the Cluster Version Operator refreshes the available updates, check if more updates are available in your current channel. + -- diff --git a/release_notes/ocp-4-6-release-notes.adoc b/release_notes/ocp-4-6-release-notes.adoc index 860d2c98e2dc..05d6b7705661 100644 --- a/release_notes/ocp-4-6-release-notes.adoc +++ b/release_notes/ocp-4-6-release-notes.adoc @@ -2437,7 +2437,7 @@ This section will continue to be updated over time to provide notes on enhanceme [IMPORTANT] ==== -For any {product-title} release, always review the instructions on xref:../updating/updating-cluster.adoc#updating-cluster[updating your cluster] properly. +For any {product-title} release, always review the instructions on xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[updating your cluster] properly. ==== [id="ocp-4-6-1-ga"] @@ -2556,7 +2556,7 @@ New {op-system} boot images are now available as part of the {product-title} 4.6 [id="ocp-4-6-8-eus-channel"] ===== EUS 4.6 upgrade channel now available -The `eus-4.6` upgrade channel is now available. This channel offers link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[Extended Update Support (EUS)]. EUS versions extend the maintenance phase for customers with Premium Subscriptions to 14 months. {product-title}. For more information, see xref:../updating/updating-cluster-between-minor.adoc#understanding-upgrade-channels_updating-cluster-between-minor[{product-title} upgrade channels and releases]. +The `eus-4.6` upgrade channel is now available. This channel offers link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[Extended Update Support (EUS)]. EUS versions extend the maintenance phase for customers with Premium Subscriptions to 14 months. {product-title}. For more information, see xref:../updating/understanding-upgrade-channels-release.adoc#understanding-upgrade-channels_understanding-upgrade-channels-releases[{product-title} upgrade channels and releases]. [id="ocp-4-6-8-upgrading"] ==== Upgrading diff --git a/security/container_security/security-hosts-vms.adoc b/security/container_security/security-hosts-vms.adoc index b704bbd190ae..8b8b5c50556a 100644 --- a/security/container_security/security-hosts-vms.adoc +++ b/security/container_security/security-hosts-vms.adoc @@ -28,7 +28,7 @@ ifndef::openshift-origin[] endif::[] * xref:../../installing/install_config/installing-customizing.adoc#installation-special-config-encrypt-disk_installing-customizing[Disk encryption] * xref:../../installing/install_config/installing-customizing.adoc#installation-special-config-chrony_installing-customizing[Chrony time service] -* xref:../../updating/updating-cluster-between-minor.adoc#update-service-overview_updating-cluster-between-minor[{product-title} cluster updates] +* xref:../../updating/understanding-the-update-service.adoc#update-service-overview_understanding-the-update-service[{product-title} cluster updates] // Virtualization versus containers include::modules/security-hosts-vms-vs-containers.adoc[leveloffset=+1] diff --git a/support/remote_health_monitoring/about-remote-health-monitoring.adoc b/support/remote_health_monitoring/about-remote-health-monitoring.adoc index bc212bc9f7b5..dd746398b475 100644 --- a/support/remote_health_monitoring/about-remote-health-monitoring.adoc +++ b/support/remote_health_monitoring/about-remote-health-monitoring.adoc @@ -13,7 +13,7 @@ A cluster that reports data to Red Hat through Telemetry and the Insights Operat The *Insights Operator* gathers {product-title} configuration data and sends it to Red Hat. The data is used to produce insights about potential issues that a cluster might be exposed to. These insights are communicated to cluster administrators on link:https://console.redhat.com/openshift[console.redhat.com/openshift]. -More information is provided in this document about these two processes. +More information is provided in this document about these two processes. .Telemetry and Insights Operator benefits @@ -37,7 +37,7 @@ include::modules/telemetry-about-telemetry.adoc[leveloffset=+1] .Additional resources -* See the xref:../../updating/updating-cluster-between-minor.adoc#updating-cluster-between-minor[{product-title} update documentation] for more information about updating or upgrading a cluster. +* See the xref:../../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[{product-title} update documentation] for more information about updating or upgrading a cluster. include::modules/telemetry-what-information-is-collected.adoc[leveloffset=+2] @@ -80,11 +80,11 @@ As further described in the preceding sections of this document, Red Hat collect .Collection safeguards -Red Hat employs technical and organizational measures designed to protect the telemetry and configuration data. +Red Hat employs technical and organizational measures designed to protect the telemetry and configuration data. .Sharing -Red Hat may share the data collected through Telemetry and the Insights Operator internally within Red Hat to improve your user experience. Red Hat may share telemetry and configuration data with its business partners in an aggregated form that does not identify customers to help the partners better understand their markets and their customers’ use of Red Hat offerings or to ensure the successful integration of products jointly supported by those partners. +Red Hat may share the data collected through Telemetry and the Insights Operator internally within Red Hat to improve your user experience. Red Hat may share telemetry and configuration data with its business partners in an aggregated form that does not identify customers to help the partners better understand their markets and their customers’ use of Red Hat offerings or to ensure the successful integration of products jointly supported by those partners. .Third party service providers diff --git a/updating/installing-update-service.adoc b/updating/installing-update-service.adoc index 090c940c69c9..906ae478dd7e 100644 --- a/updating/installing-update-service.adoc +++ b/updating/installing-update-service.adoc @@ -12,12 +12,10 @@ toc::[] For clusters with internet accessibility, Red Hat provides over-the-air updates through an OpenShift Container Platform update service as a hosted service located behind public APIs. However, clusters in a restricted network have no way to access public APIs for update information. -To provide a similar upgrade experience in a restricted network, you can install and configure the OpenShift Update Service locally so that it is available within a disconnected environment. +To provide a similar upgrade experience in a restricted network, you can install and configure the OpenShift Update Service locally so that it is available within a disconnected environment. The following sections describe how to provide over-the-air updates for your disconnected cluster and its underlying operating system. -include::modules/update-service-overview.adoc[leveloffset=+1] - [id="update-service-prereqs"] == Prerequisites diff --git a/updating/understanding-upgrade-channels-release.adoc b/updating/understanding-upgrade-channels-release.adoc new file mode 100644 index 000000000000..6bbff05f0abd --- /dev/null +++ b/updating/understanding-upgrade-channels-release.adoc @@ -0,0 +1,30 @@ +[id="understanding-upgrade-channels-releases"] += Understanding upgrade channels and releases +include::modules/common-attributes.adoc[] +:context: understanding-upgrade-channels-releases + +toc::[] + +In {product-title} 4.1, Red Hat introduced the concept of channels for recommending the appropriate release versions for cluster upgrades. By controlling the pace of upgrades, these upgrade channels allow you to choose an upgrade strategy. Upgrade channels are tied to a minor version of {product-title}. For instance, {product-title} 4.6 upgrade channels recommend upgrades to 4.6 and upgrades within 4.6. They also recommend upgrades within 4.5 and from 4.5 to 4.6, to allow clusters on 4.5 to eventually upgrade to 4.6. They do not recommend upgrades to 4.7 or later releases. This strategy ensures that administrators explicitly decide to upgrade to the next minor version of {product-title}. + +Upgrade 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 upgrade channels: + +* `candidate-{product-version}` +* `fast-{product-version}` +* `stable-{product-version}` +* `eus-4.y` (only when running an even-numbered 4.y cluster release, like 4.6) + +If you do not want the Cluster Version Operator to fetch available updates from the upgrade 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 upgrade recommendation service. + +endif::openshift-origin[] +ifdef::openshift-origin[] +{product-title} {product-version} offers the following upgrade channel: + +* `stable-4` + +endif::openshift-origin[] + +include::modules/understanding-upgrade-channels.adoc[leveloffset=+1] diff --git a/updating/updating-cluster-cli.adoc b/updating/updating-cluster-cli.adoc index 13d4d0bbc3fa..51c141790870 100644 --- a/updating/updating-cluster-cli.adoc +++ b/updating/updating-cluster-cli.adoc @@ -1,5 +1,5 @@ [id="updating-cluster-cli"] -= Updating a cluster within a minor version by using the CLI += Updating a cluster within a minor version using the CLI include::modules/common-attributes.adoc[] :context: updating-cluster-cli @@ -21,13 +21,10 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis Using the `unsupportedConfigOverrides` section to modify the configuration of an Operator is unsupported and might block cluster upgrades. You must remove this setting before you can upgrade your cluster. ==== -include::modules/update-service-overview.adoc[leveloffset=+1] .Additional resources * xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators] -include::modules/understanding-upgrade-channels.adoc[leveloffset=+1] - include::modules/update-upgrading-cli.adoc[leveloffset=+1] include::modules/update-changing-update-server-cli.adoc[leveloffset=+1] diff --git a/updating/updating-cluster-rhel-compute.adoc b/updating/updating-cluster-rhel-compute.adoc index 1025ca46f99b..10a4563a05c3 100644 --- a/updating/updating-cluster-rhel-compute.adoc +++ b/updating/updating-cluster-rhel-compute.adoc @@ -16,13 +16,10 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis * Have a recent xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your upgrade fails and you must xref:../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state]. * If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see _Upgrading clusters with manually maintained credentials_ for xref:../installing/installing_aws/manually-creating-iam.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-aws[AWS], xref:../installing/installing_azure/manually-creating-iam-azure.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-azure[Azure], or xref:../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-gcp[GCP]. -include::modules/update-service-overview.adoc[leveloffset=+1] .Additional resources * xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators] -include::modules/understanding-upgrade-channels.adoc[leveloffset=+1] - include::modules/update-upgrading-web.adoc[leveloffset=+1] [id="updating-cluster-rhel-compute-hooks"] diff --git a/updating/updating-cluster-between-minor.adoc b/updating/updating-cluster-within-minor.adoc similarity index 88% rename from updating/updating-cluster-between-minor.adoc rename to updating/updating-cluster-within-minor.adoc index 30273f50129a..f518565821f0 100644 --- a/updating/updating-cluster-between-minor.adoc +++ b/updating/updating-cluster-within-minor.adoc @@ -1,12 +1,11 @@ -[id="updating-cluster-between-minor"] -= Updating a cluster between minor versions +[id="updating-cluster-within-minor"] += Updating a cluster within a minor version using the web console include::modules/common-attributes.adoc[] -:context: updating-cluster-between-minor +:context: updating-cluster-within-minor toc::[] -You can update, or upgrade, an {product-title} cluster between minor versions. - +You can update, or upgrade, an {product-title} cluster by using the web console. The following steps are updating a cluster within a minor a version. You can use the same instructions for updating a cluster between minor versions. [NOTE] ==== Because of the difficulty of changing update channels by using `oc`, use the web console to change the update channel. It is recommended to complete the update process within the web console. You can follow the steps in xref:../updating/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster within a minor version by using the CLI] to complete the update after you change to a {product-version} channel. @@ -26,12 +25,10 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis Using the `unsupportedConfigOverrides` section to modify the configuration of an Operator is unsupported and might block cluster upgrades. You must remove this setting before you can upgrade your cluster. ==== -include::modules/update-service-overview.adoc[leveloffset=+1] .Additional resources * xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators] -include::modules/understanding-upgrade-channels.adoc[leveloffset=+1] include::modules/update-upgrading-web.adoc[leveloffset=+1] diff --git a/welcome/index.adoc b/welcome/index.adoc index 12ab0c56be86..b9e0a7f007e2 100644 --- a/welcome/index.adoc +++ b/welcome/index.adoc @@ -226,7 +226,7 @@ endif::[] - **Update a cluster**: To upgrade your {product-title} to a later version, use the Cluster Version Operator (CVO). -If an update is available from the Container Platform update service, you apply that cluster update from either the xref:../updating/updating-cluster.adoc#updating-cluster[web console] or the xref:../updating/updating-cluster-cli.adoc#updating-cluster-cli[CLI]. +If an update is available from the Container Platform update service, you apply that cluster update from either the xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[web console] or the xref:../updating/updating-cluster-cli.adoc#updating-cluster-cli[CLI]. //// There is a separate process for diff --git a/welcome/learn_more_about_openshift.adoc b/welcome/learn_more_about_openshift.adoc index b959b4ca0c74..4f8e3e6bb7a4 100644 --- a/welcome/learn_more_about_openshift.adoc +++ b/welcome/learn_more_about_openshift.adoc @@ -68,7 +68,7 @@ Use the following sections to find content to help you learn about and use {prod | | -| xref:../updating/updating-cluster-between-minor.adoc#updating-cluster-between-minor[Updating a cluster] +| xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[Updating a cluster] | | diff --git a/whats_new/new-features.adoc b/whats_new/new-features.adoc index 0afea65e7a0a..c84a13c2fd5c 100644 --- a/whats_new/new-features.adoc +++ b/whats_new/new-features.adoc @@ -59,7 +59,7 @@ Easy, over-the-air upgrades for asynchronous z-stream releases of OpenShift v4 is available. Cluster administrators can upgrade using the *Cluster Settings* tab in the web console. See -xref:../updating/updating-cluster.adoc#updating-cluster[Updating a cluster] +xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[Updating a cluster] for more information. [id="ocp-operator-hub"]