openshift · sagidlow · Dec 7, 2021
diff --git a/_javascripts/page-loader.js b/_javascripts/page-loader.js
@@ -115,8 +115,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
@@ -433,11 +433,13 @@ 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: Understanding upgrade channels
+  File: understanding-upgrade-channels-release
 - 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
+  File: updating-cluster-within-minor
+# - Name: Updating a cluster within a minor version from the web console
+#  File: updating-cluster
+- Name: Updating a cluster within a minor version using the CLI
   File: updating-cluster-cli
 - Name: Performing update using canary rollout strategy
   File: update-using-custom-machine-config-pools

diff --git a/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc b/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc
@@ -37,4 +37,4 @@ include::modules/ipi-install-verifying-static-ip-address-configuration.adoc[leve
 
 .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/updating-cluster-within-minor.adoc#understanding-upgrade-channels_updating-cluster-within-minor[{product-title} upgrade channels and releases] for an explanation of the different release channels.
diff --git 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/updating-cluster-within-minor.adoc#understanding-upgrade-channels_updating-cluster-within-minor[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
@@ -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
@@ -5,35 +5,11 @@
 // * updating/updating-cluster-cli.adoc
 // * updating/updating-cluster-rhel-compute.adoc
 // * updating/updating-disconnected-cluster.adoc
+// * updating/understanding-upgrade-channels-release.adoc
 
 [id="understanding-upgrade-channels_{context}"]
-= {product-title} upgrade channels and releases
 
-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.9 upgrade channels recommend upgrades to 4.9 and upgrades within 4.9. They also recommend upgrades within 4.8 and from 4.8 to 4.9, to allow clusters on 4.8 to eventually upgrade to 4.9. They do not recommend upgrades to 4.10 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.10)
-
-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[]
-
-ifndef::openshift-origin[]
-[discrete]
-== candidate-{product-version} channel
+= 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.
 
@@ -51,44 +27,42 @@ endif::[]
 for more build information.
 ====
 
-[discrete]
-== fast-{product-version} channel
+= 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]
-== stable-{product-version} channel
+
+= 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]
-== stable-4 channel
+
+= stable-4 channel
 Releases are added to the `stable-4` channel after passing all tests.
 
 You can use the `stable-4` channel to upgrade from a previous minor version of {product-title}.
 endif::openshift-origin[]
 
 ifndef::openshift-origin[]
-[discrete]
-== eus-4.y channel
+
+= 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). These EUS versions extend the Full and Maintenance support phases for customers with Standard and Premium Subscriptions to 18 months.
 
-Although there is no difference between `stable-4.y` and `eus-4.y` channels until {product-title} 4.y transitions to the EUS phase, you can switch to the `eus-4.y` channel as soon as it becomes available. 
+Although there is no difference between `stable-4.y` and `eus-4.y` channels until {product-title} 4.y transitions to the EUS phase, you can switch to the `eus-4.y` channel as soon as it becomes available.
 
 When upgrades to the next EUS channel are offered, you can switch to the next EUS channel and upgrade until you have reached the next EUS version.
 
 This upgrade process does not apply for the `eus-4.6` channel.
 endif::openshift-origin[]
 
-[discrete]
-== Upgrade version paths
+= 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.
 
@@ -117,22 +91,21 @@ The presence of an update recommendation in the `stable-4` channel at any point
 endif::openshift-origin[]
 
 ifndef::openshift-origin[]
-[discrete]
-== Fast and stable channel use and strategies
+
+= 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.
 
 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]
-== Restricted network clusters
+= 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]
-== Switching between channels
+
+= Switching between channels
 
 A channel can be switched from the web console or through the `adm upgrade channel` command:
 

diff --git a/post_installation_configuration/cluster-tasks.adoc b/post_installation_configuration/cluster-tasks.adoc
@@ -142,7 +142,7 @@ You use these resources to retrieve information about the cluster. Some configur
 |`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/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/updating-cluster-within-minor.adoc#update-service-overview_updating-cluster-within-minor[{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
@@ -16,7 +16,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
 
@@ -41,7 +41,7 @@ include::modules/telemetry-about-telemetry.adoc[leveloffset=+1]
 ifndef::openshift-dedicated[]
 .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.
 endif::[]
 
 include::modules/telemetry-what-information-is-collected.adoc[leveloffset=+2]
@@ -95,11 +95,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/understanding-upgrade-channels-release.adoc b/updating/understanding-upgrade-channels-release.adoc
@@ -0,0 +1,33 @@
+[id="understanding-upgrade-channels-releases"]
+= Understanding upgrade channels and releases
+include::module/common-attributes.adoc[]
+:context: understanding-upgrade-channels-release
+
+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.9 upgrade channels recommend upgrades to 4.9 and upgrades within 4.9. They also recommend upgrades within 4.8 and from 4.8 to 4.9, to allow clusters on 4.8 to eventually upgrade to 4.9. They do not recommend upgrades to 4.10 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.10)
+
+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[]
+
+ifndef::openshift-origin[]
+
+include::modules/understanding-upgrade-channels.adoc[leveloffset=+1]
Original file line number	Diff line number	Diff line change
Expand Up		@@ -37,4 +37,4 @@ include::modules/ipi-install-verifying-static-ip-address-configuration.adoc[leve

		.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/updating-cluster-within-minor.adoc#understanding-upgrade-channels_updating-cluster-within-minor[{product-title} upgrade channels and releases] for an explanation of the different release channels.