Merge pull request #54165 from obrown1205/conditionType_definitions

OSDOCS-2439: Adding section for defining conditionTypes to

Author: mburke5678

modules/determining-upgrade-viability-conditiontype.adoc

@@ -0,0 +1,43 @@
+// Module included in the following assemblies:
+//
+// * updating/index.adoc
+
+:_content-type: CONCEPT
+[id="Understanding_clusteroperator_conditiontypes_{context}"]
+= Understanding cluster Operator condition types
+
+The status of cluster Operators includes their condition type, informing you of the current state of your Operator's health. The following definitions cover a list of some common ClusterOperator condition types. Operators that have additional condition types and use Operator-specific language have been omitted. 
+
+The Cluster Version Operator (CVO) is responsible for collecting the status conditions from cluster Operators so that cluster administrators can better understand the state of the {product-title} cluster.
+
+//Condition types, as well as additional information about your operator, can be retrieved in either YAML or JSON format through the `oc get clusterversion -o` command:
+
+//[source,terminal]
+//----
+//$ oc get clusterversion -o yaml
+//----
+
+
+* Available: 
+An Operator with the condition type `Available` is functional and available in the cluster. If the status is `False`, at least one part of the operand is non-functional and the condition requires an administrator to intervene.
+
+* Progressing:
+An Operator with the condition type `Progressing` is actively rolling out new code, propagating configuration changes, or otherwise moving from one steady state to another. 
++
+Operators do not report the condition type `Progressing` as `True` when they are reconciling a previous known state. If the observed cluster state has changed and the Operator is reacting to it, then the status will report back as `True`, since it is moving from one steady state to another.
++
+* Degraded:
+An Operator with the condition type `Degraded` has a current state that does not match the required state over a period of time. The period of time can vary by component, but a `Degraded` state represents persistent observation of an Operator's condition.  As a result, an Operator will not fluctuate in and out of the `Degraded` state.  
++
+There might be a different condition type if the transition from one state to another does not persist over a long enough period to report `Degraded`.  
+An Operator will not report `Degraded` during the course of a normal upgrade.  An Operator may report `Degraded` in response to a persistent infrastructure failure that requires eventual administrator intervention.
++
+[NOTE]
+====
+This condition type is only an indication that something may need investigation and adjustment. As long as the Operator is available, the `Degraded` condition does not cause user workload failure or application downtime.
+====
++
+* Upgradeable:
+An Operator with the condition type `Upgradeable` indicates whether the Operator is safe to upgrade based on the current cluster state. The message field will contain a human-readable description of what the administrator needs to do for the cluster to successfully update. The CVO allows updates when this condition is `True`, `Unknown` or missing. 
++
+When the `Upgradeable` status is `False`, only minor updates are impacted, and the CVO prevents the cluster from performing impacted updates unless forced.

updating/index.adoc

@@ -22,6 +22,8 @@ xref:../updating/understanding-upgrade-channels-release.adoc#understanding-upgra
 * xref:../updating/understanding-upgrade-channels-release.adoc#switching-between-channels_understanding-upgrade-channels-releases[Switching between channels]
 * xref:../updating/understanding-upgrade-channels-release.adoc#conditional-updates-overview_understanding-upgrade-channels-releases[Understanding conditional updates]
 
+include::modules/determining-upgrade-viability-conditiontype.adoc[leveloffset=+1]
+
 [id="updating-clusters-overview-prepare-eus-to-eus-update"]
 == Preparing to perform an EUS-to-EUS update
 xref:../updating/preparing-eus-eus-upgrade.adoc#preparing-eus-eus-upgrade[Preparing to perform an EUS-to-EUS update]: Due to fundamental Kubernetes design, all {product-title} updates between minor versions must be serialized. You must update from {product-title} 4.9 to 4.10, and then to 4.11. You cannot update from {product-title} 4.8 to 4.10 directly. However, if you want to update between two Extended Update Support (EUS) versions, you can do so by incurring only a single reboot of non-control plane hosts. For more information, see the following: