Merge pull request #41736 from adellape/conditions_note

Author: adellape

modules/olm-operatorconditions-about.adoc

@@ -15,3 +15,8 @@ endif::[]
 As part of its role in managing the lifecycle of an Operator, Operator Lifecycle Manager (OLM) infers the state of an Operator from the state of Kubernetes resources that define the Operator. While this approach provides some level of assurance that an Operator is in a given state, there are many instances where an Operator might need to communicate information to OLM that could not be inferred otherwise. This information can then be used by OLM to better manage the lifecycle of the Operator.
 
 OLM provides a custom resource definition (CRD) called `OperatorCondition` that allows Operators to communicate conditions to OLM. There are a set of supported conditions that influence management of the Operator by OLM when present in the `Spec.Conditions` array of an `OperatorCondition` resource.
+
+[NOTE]
+====
+By default, the `Spec.Conditions` array is not present in an `OperatorCondition` object until it is either added by a user or as a result of custom Operator logic.
+====

modules/olm-overriding-operatorconditions.adoc

@@ -8,15 +8,20 @@
 
 As a cluster administrator, you might want to ignore a supported Operator condition reported by an Operator. When present, Operator conditions in the `Spec.Overrides` array override the conditions in the `Spec.Conditions` array, allowing cluster administrators to deal with situations where an Operator is incorrectly reporting a state to Operator Lifecycle Manager (OLM).
 
-For example, consider a known version of an Operator that always communicates that it is not upgradeable. In this instance, you might want to upgrade the Operator despite the Operator communicating that it is not upgradeable. This could be accomplished by overriding the Operator condition by adding the condition `type` and `status` to the `Spec.Overrides` array in the `OperatorCondition` resource.
+[NOTE]
+====
+By default, the `Spec.Overrides` array is not present in an `OperatorCondition` object until it is added by a cluster administrator. The `Spec.Conditions` array is also not present until it is either added by a user or as a result of custom Operator logic.
+====
+
+For example, consider a known version of an Operator that always communicates that it is not upgradeable. In this instance, you might want to upgrade the Operator despite the Operator communicating that it is not upgradeable. This could be accomplished by overriding the Operator condition by adding the condition `type` and `status` to the `Spec.Overrides` array in the `OperatorCondition` object.
 
 .Prerequisites
 
-* An Operator with an `OperatorCondition` resource, installed using OLM.
+* An Operator with an `OperatorCondition` object, installed using OLM.
 
 .Procedure
 
-. Edit the `OperatorCondition` resource for the Operator:
+. Edit the `OperatorCondition` object for the Operator:
 +
 [source,terminal]
 ----