Managing Operator conditions
As a cluster administrator, you might want to ignore a supported Operator condition reported by an Operator. When present, Operator conditions in the 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.
- An Operator with an
OperatorCondition
resource, installed using OLM.
Procedure
Edit the
OperatorCondition
resource for the Operator:-
Example Operator condition override
kind: OperatorCondition
name: my-operator
namespace: operators
spec:
overrides:
- type: Upgradeable (1)
reason: "upgradeIsSafe"
message: "This is a known issue with the Operator where it always reports that it cannot be upgraded."
conditions:
- type: Upgradeable
reason: "migration"
message: "The operator is performing a migration."
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.
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.