OSDOCS-6618: Update availability FAQ

Author: skopacz1

modules/update-availability-faq.adoc

@@ -0,0 +1,65 @@
+// Module included in the following assemblies:
+//
+// * updating/understanding-openshift-updates.adoc
+
+:_content-type: CONCEPT
+[id="update-availability_{context}"]
+= Common questions about update availability
+
+There are several factors that affect if and when an update is made available to an {product-title} cluster. The following list provides common questions regarding the availability of an update:
+
+[id="channel-differences_{context}"]
+*What are the differences between each of the update channels?*
+
+* A new release is initially added to the `candidate` channel.
+
+* After successful final testing, a release on the `candidate` channel is promoted to the `fast` channel, an errata is published, and the release is now fully supported.
+
+* After a delay, a release on the `fast` channel is finally promoted to the `stable` channel. This delay represents the only difference between the `fast` and `stable` channels.
++
+[NOTE]
+====
+For the latest z-stream releases, this delay may generally be a week or two. However, the delay for initial updates to the latest minor version may take much longer, generally 45-90 days.
+====
+
+* Releases promoted to the `stable` channel are simultaneously promoted to the `eus` channel.
+The primary purpose of the `eus` channel is to serve as a convenience for clusters performing an EUS-to-EUS update.
+
+[id="channel-safety_{context}"]
+*Is a release on the `stable` channel safer or more supported than a release on the `fast` channel?*
+
+* If a regression is identified for a release on a `fast` channel, it will be resolved and managed to the same extent as if that regression was identified for a release on the `stable` channel.
+
+* The only difference between releases on the `fast` and `stable` channels is that a release only appears on the `stable` channel after it has been on the `fast` channel for some time, which provides more time for new update risks to be discovered.
+
+[id="supported-updates_{context}"]
+*What does it mean if an update is supported but not recommended?*
+
+* Red Hat continuously evaluates data from multiple sources to determine whether updates from one version to another lead to issues.
+If an issue is identified, an update path may no longer be recommended to users.
+However, even if the update path is not recommended, customers are still supported if they perform the update.
+
+* Red Hat does not block users from updating to a certain version.
+Red Hat may declare conditional update risks, which may or may not apply to a particular cluster.
+
+** Declared risks provide cluster administrators more context about a supported update.
+Cluster administrators can still accept the risk and update to that particular target version.
+This update is always supported despite not being recommended in the context of the conditional risk.
+
+[id="removed-recommendation_{context}"]
+*What if I see that an update to a particular release is no longer recommended?*
+
+* If Red Hat removes update recommendations from any supported release due to a regression, a superseding update recommendation will be provided to a future version that corrects the regression.
+There may be a delay while the defect is corrected, tested, and promoted to your selected channel.
+
+[id="z-stream-release-cadence_{context}"]
+*How long until the next z-stream release is made available on the fast and stable channels?*
+
+* While the specific cadence can vary based on a number of factors, new z-stream releases for the latest minor version are typically made available about every week. Older minor versions, which have become more stable over time, may take much longer for new z-stream releases to be made available.
++
+[IMPORTANT]
+====
+These are only estimates based on past data about z-stream releases. Red Hat reserves the right to change the release frequency as needed. Any number of issues could cause irregularities and delays in this release cadence.
+====
+
+* Once a z-stream release is published, it also appears in the `fast` channel for that minor version. After a delay, the z-stream release may then appear in that minor version's `stable` channel.

updating/understanding_updates/intro-to-updates.adoc

@@ -28,6 +28,13 @@ As the CVO applies a manifest to a cluster Operator, the Operator might perform
 The CVO monitors the state of each applied resource and the states reported by all cluster Operators. The CVO only proceeds with the update when all manifests and cluster Operators in the active Runlevel reach a stable condition.
 After the CVO updates the entire control plane through this process, the Machine Config Operator (MCO) updates the operating system and configuration of every node in the cluster.
 
+include::modules/update-availability-faq.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../updating/understanding-upgrade-channels-release.adoc#understanding-upgrade-channels-releases[Understanding update channels and releases]
+
 include::modules/update-service-overview.adoc[leveloffset=+1]
 
 include::modules/update-common-terms.adoc[leveloffset=+1]