Data Grid 8 Operators coexistence in a same Openshift cluster

Environment

• Red hat OpenShift Container Platform (OCP)
  • 4.x
• Red Hat Data Grid (RHDG)
  • 8 Operator

Issue

• Can one have two DG 8 Operators in the same cluster?
• Can user have two DG 8 in the same cluster?

Resolution

It is not supported to have multiple versions of the DG Operator in the same OCP cluster

The coexistence of different DG versions in the same cluster could sometimes work, but it's not a supported use case in general: since CRDs are common to the whole OCP cluster, old versions can conflict with new definitions.

The component that sets the scope of the DG Operator is the OperatorGroups (aka OG), which is set as follows:

• in case it brings no .spec details, it will be cluster-wide
• in case it brings target namespace in the .spec details, it will be namespace bounded

Therefore, Intersecting OperatorGroups issue is caused by multiple operators installed, targeting same namespaces (or wrong configured OperatorGroups).

Given the above:

• For cluster-wide installations the installation is done in openshift-operators - because it has a OG with no target namespace
• For namespace specific the operator namespace's installation is set on the subscription and the target namespace is set on Operator Groups, which are objects that connect between the operator namespace and the target namespace, which is the namespace the operator will listen to APIs creations (cluster, cache).

Using multiple versions of Data Grid Operand (not Data Grid Operator versions - but Operand)

Starting on DG Operator 8.4, the user can have a single Data Grid Operator installation that supports multiple versions of Data Grid, which we call Operands. For doing so use spec.version field in your Infinispan CR to upgrade between supported versions.

Example:

• Data Grid Operator version 8.4 supports the following Data Grid versions (for DG Operator 8.4.1.csv):

For more details on the DG Operator <-> DG Operand (DG server) association, see the solution Association between DG Operator and DG Server version/DG Operands.

FAQ

Q1. Can I have multiple DG Operator versions in the same OCP cluster?
A1. No. That's not supported because they will certainly collide given CRD are cluster wide.

Q2. Can I have multiple DG versions in the same OCP cluster?
A2. Starting on DG 8.4 Operator, it can (with limitations) support different versions of clusters: DG 8.3.1 and DG 8.4.0 in the same DG Operator.

Q3. User has Dg Operator 8.4.1 and deployed a Infinispan CR with version 8.4.0, can it be downgraded?
A3. Downgrade is not allowed.

Root Cause

Operators can be installed namespace bounded (one Operator listening to one namespace) or cluster-wide (one operator for all the OCP cluster).
Having multiple operators of the same DG Operator version is possible given a namespace bounded operator - which is set by OperatorGroup's target namespaces. However, when the upgrade is done in one, it must be done for all - to avoid CRDs conflicts. Meaning DG Operator upgrade in one namespace means to do upgrade for all the namespaces - sequentially.

Given one operator with specific namespace (let's say A) and another cluster wide (same version), they are incompatible and you cannot install both - at the same time. The following messages can be seeing:

Danger alert:Installation Failed
Failed: intersecting operatorgroups provide the same apis

And the namespace in question is A because there would be two DG 8 Operators managing the same namespace A.

Otherwise, manually installing it, even though the install plan will be approved but the message (on the Install Plan) will have message: more than one operator group(s) are managing this namespace count=2.

For migration step, see solution How to migrate from DG 8.1/8.2 to DG 8.3 in DG 8 Operator.

Diagnostic Steps

Get IP -o yaml output:

$ oc get ip -o yaml | grep message
      - message: bundle contents have not yet been persisted to installplan status
      - message: unpack job not yet started
      message: more than one operator group(s) are managing this namespace count=2

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.