modules/understanding-upgrade-channels: Focus on risk declaration, not update removal

Before 4.10, we used to remove the recommended update entirely.  That
resulted in some "where did my recommended update to 4.y.z go?"
confusion.  To address this, we developed conditional updates [1], and
since 4.10, semantically channel updates from A to B can be either:

* Unconditional, A-to-B supported and recommended for all clusters.
* Conditional, A-to-B supported, but only recommended for some subset
  of clusters, with human and machine-readable metadata to explain the
  risk.

While a transition from the former to the latter can be phrased as
"removing an unconditional recommendation" (and replacing it with a
conditional recommendation), nobody actually cares directly about
whether the update was recommended.  Things that customers care about
are:

* Whether they will have support if they hit a bug.  But declared
  risks have no impact on whether they'll get that support.
* Whether they'll hit a bug.  And the new risk declarations get their
  exposure information out in front of customers before they update,
  instead of leaving that exposure information to word-of-mouth or
  surprising customers when they get bit.

With the new information about the risk, admins are empowered to
evaluate their exposure, and to do any of:

* Waive the risk and update.  Even if they get bit, the early warning
  may have given them time to prepare a recovery/mitigation.
* Prepare the cluster ahead of time, by removing problematic
  conditions while in their current release, until their cluster no
  longer matches any known risks.
* Wait for a new release to ship with a fix that removes exposure to
  the risk.

While before the risk was declared, their choice was:

* Update blind to the risk.  If you get bit, you have no idea, and
  have to figure out what's going on on the fly.

I'm using "confirmed" from Yang's suggested rewording [2], to hint
that there is an assessment process between a potential-regression
report and an update risk being declared [3].

I'm using generic wording for "recommended" and "supported but not
recommended" instead of trying to quote user interfaces, because 'oc
adm upgrade' and the in-cluster web console don't quite agree on
wording:

* Recommended:
  * oc: "Recommended updates" [4].
  * web-console: "Recommended" [5].
* Supported but not recommended:
  * oc: "Supported but not recommended updates" [6].
  * web-console: "Include supported but not recommended versions" [7].

[1]: https://github.com/openshift/enhancements/blob/6b3209fa18ab3161429743550eed36391efc785f/enhancements/update/targeted-update-edge-blocking.md
[2]: #58771 (comment)
[3]: https://github.com/openshift/enhancements/blob/ba306451b99da182d26bd0631f3f1e448930316c/enhancements/update/update-blocker-lifecycle/README.md
[4]: https://github.com/openshift/oc/blame/f843bb1e3acc667e60fd6831afbc6da5b0063518/pkg/cli/admin/upgrade/upgrade.go#LL417C26-L417C46
[5]: https://github.com/openshift/console/blob/07fe8898570666409b38e46630559da6e3adf25f/frontend/public/components/modals/cluster-update-modal.tsx#L178
[6]: https://github.com/openshift/oc/blame/f843bb1e3acc667e60fd6831afbc6da5b0063518/pkg/cli/admin/upgrade/upgrade.go#L441
[7]: https://github.com/openshift/console/blob/07fe8898570666409b38e46630559da6e3adf25f/frontend/public/components/modals/cluster-update-modal.tsx#L210

Author: wking

modules/understanding-upgrade-channels.adoc

@@ -69,12 +69,14 @@ Do not rely on consecutive patch numbers. In this example, {product-version}.2 i
 ====
 
 [id="conditional-updates-overview_{context}"]
-== Update recommendation removals 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 a serious regression is identified, Red Hat may remove affected update recommendations. When Red Hat chooses to remove update recommendations, that action is taken in all relevant channels simultaneously. The removal of recommended updates may happen either before or after updates have been promoted to supported channels.
+== 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 recommendations are removed from supported channels, they are replaced with Conditional Updates that declare one or more known risks. 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 updates are listed as a `Supported But Not Recommended` update and a reference link is provided. The reference link helps the cluster admin decide if they would like to accept the risk and update anyway.
+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 updates are supported but not recommended, and a reference link is provided. The reference link helps the cluster admin decide if they would like to accept the risk and update anyway.
+
+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[]