How can Operators be updated independently from each other?

Solution Verified - Updated

Environment

  • Red Hat OpenShift Container Platform (RHOCP) 4
  • Operator Lifecycle Manager

Issue

  • InstallPlans are referencing more than one operator. The InstallPlans for an operator should be distinct from other operators.

  • While using different operators in openshift-operators namespace. The different subscriptions are deployed with either automatic or manual approvalMode. It's expected that the install plans of an operator are distinct from other operators. But, InstallPlans are referencing more than one operator and an InstallPlan contains all operators that could be updated. If one of the operators have approvalMode Manual rest of the operators will not update though they have been subscribed with Automatic mode.

  • Updating an operator in the openshift-operators namespace triggers an update of all Operators in the namespace.

  • When an operator is configured with an automatic approvalMode , the OpenShift GUI displays the Update approval status as Automatic Functioning as manual.

  • We have several operators installed in our cluster and currently have the subscription for each operator set to "manual" approval to ensure upgrades are planned and appropriately tested/validated. However, when I go to approve the single operator I want to upgrade, OpenShift creates an install plan for ALL POSSIBLE operators that can be upgraded and asks me to approve upgrades for all. Is it not possible to upgrade a single operator through OLM?

  • How do I upgrade just a single operator at a time in OpenShift?

Resolution

  • Install Plans are referenced by more than one Operator and this is the current intended behavior. In the future, this will change due to an API re-design of OLM which will operate at the cluster-scope. The way to avoid this with today's API is by installing the operators into separate namespaces.

  • As of now OLM can handle the Operators independently, but there are manual steps needed. As a workaround, create a new OperatorGroup object, subscribe a namespace to the Operator in AllNamespaces mode, the namespace needs to be different than openshift-operators. Full workaround description is found in the documentation.

  • There was an open feature request This content is not included.OLM-2151 regarding changing this default behavior. From RHOCP 4.14 version, we have launched Operator Lifecycle Manager OLM v1.0 which will be in the Technical Preview for now. This will give improved insight into catalog content, administrators can specify target versions for installation and updates. This grants administrators more control over the target version of Operator updates.

Root Cause

  • This behavior is currently expected, due to the namespaced API design and dependency resolution of OLM. Current API design and dependency resolution causes all Operators in a namespace, related by dependencies or not, to be treated as one big set to install / upgrade and fail / succeed altogether.

  • The OLM UI defaults all global operators into the same namespace (openshift-operators), that causes this side effect.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.