---
title: Managing Operator conditions
---

# Managing Operator conditions {#olm-managing-operatorconditions}

You can manage Operator conditions in OpenShift Container Platform by using Operator Lifecycle Manager (OLM).

## Overriding Operator conditions {#olm-supported-operatorconditions_olm-managing-operatorconditions}

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).

> [!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**

- You have access to the cluster as a user with the `cluster-admin` role.
- An Operator with an `OperatorCondition` object, installed using OLM.

**Procedure**

1. Edit the `OperatorCondition` object for the Operator:

   ```terminal
   $ oc edit operatorcondition <name>
   ```
2. Add a `Spec.Overrides` array to the object:

   ```yaml {title="Example Operator condition override"}
   apiVersion: operators.coreos.com/v2
   kind: OperatorCondition
   metadata:
     name: my-operator
     namespace: operators
   spec:
     overrides:
     - type: Upgradeable
       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"
   ```

   Setting the 'type' field to `Upgradeable` allows the cluster administrator to change the upgrade readiness to `True`.

## Updating your Operator to use Operator conditions {#olm-updating-use-operatorconditions_olm-managing-operatorconditions}

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 resources about setting Operator conditions as an Operator author, see the [Enabling Operator conditions](https://docs.openshift.com/container-platform/4.12/operators/operator_sdk/osdk-generating-csvs.html#osdk-operatorconditions_osdk-generating-csvs) page.

### Setting defaults {#olm-updating-use-operatorconditions-defaults_olm-managing-operatorconditions}

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.

**Additional resources**
{._additional-resources}

- [Operator conditions](/openshift-docs-markdown/operators/understanding/olm/olm-operatorconditions#olm-operatorconditions)