$ oc edit operatorcondition <name>
As a cluster administrator, you can manage Operator conditions by using Operator Lifecycle Manager (OLM).
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).
By default, the |
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.
An Operator with an OperatorCondition
object, installed using OLM.
Edit the OperatorCondition
object for the Operator:
$ oc edit operatorcondition <name>
Add a Spec.Overrides
array to the object:
apiVersion: operators.coreos.com/v1
kind: OperatorCondition
metadata:
name: my-operator
namespace: operators
spec:
overrides:
- type: Upgradeable (1)
status: "True"
reason: "upgradeIsSafe"
message: "This is a known issue with the Operator where it always reports that it cannot be upgraded."
conditions:
- type: Upgradeable
status: "False"
reason: "migration"
message: "The operator is performing a migration."
lastTransitionTime: "2020-08-24T23:15:55Z"
1 | Allows the cluster administrator to change the upgrade readiness to True . |
Operator Lifecycle Manager (OLM) automatically creates an OperatorCondition
resource for each ClusterServiceVersion
resource that it reconciles. All service accounts in the CSV are granted the RBAC to interact with the OperatorCondition
owned by the Operator.
An Operator author can develop their Operator to use the operator-lib
library such that, after the Operator has been deployed by OLM, it can set its own conditions. For more on writing logic to set Operator conditions as an Operator author, see the Operator SDK documentation.
In an effort to remain backwards compatible, OLM treats the absence of an OperatorCondition
resource as opting out of the condition. Therefore, an Operator that opts in to using Operator conditions should set default conditions before the ready probe for the pod is set to true
. This provides the Operator with a grace period to update the condition to the correct state.