Operator conditions
This guide outlines how Operator Lifecycle Manager (OLM) uses Operator conditions.
About Operator conditions
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.
Supported conditions
Operator Lifecycle Manager (OLM) supports the following Operator conditions.
Upgradeable condition
The Upgradeable
Operator condition prevents an existing cluster service version (CSV) from being replaced by a newer version of the CSV. This condition is useful when:
An Operator is about to start a critical process and should not be upgraded until the process is completed.
An Operator is performing a migration of custom resources (CRs) that must be completed before the Operator is ready to be upgraded.
Example Upgradeable
Operator condition
apiVersion: operators.coreos.com/v1
kind: OperatorCondition
metadata:
name: my-operator
namespace: operators
spec:
conditions:
- type: Upgradeable (1)
status: "False" (2)
reason: "migration"
message: "The Operator is performing a migration."
lastTransitionTime: "2020-08-24T23:15:55Z"
1 | Name of the condition. |
2 | A False value indicates the Operator is not ready to be upgraded. OLM prevents a CSV that replaces the existing CSV of the Operator from leaving the Pending phase. |