openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-06 15:46:57 +01:00
Code Issues Releases Activity

Add notes re: default OperatorConditions overrides & conditions

Browse Source
This commit is contained in:
Alex Dellapenta
2022-02-10 14:24:15 -07:00
committed by openshift-cherrypick-robot
parent e9a30e9b7b
commit 297e2d1099
2 changed files with 13 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
modules/olm-operatorconditions-about.adoc
View File

@@ -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.
====

11
modules/olm-overriding-operatorconditions.adoc
View File

@@ -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]
----