Request for Ansible Playbooks to support multiple catalogs in OpenShift

Superseded by https://bigblue.aha.io/ideas/ideas/MASCOM-I-119

After consulting with IBM on 2/24/2025, we agreed to revise the idea to, "Introduce the ability to specify a supported version of the catalog during installation time to better support multi0ple implementations of MAS within the same OS Cluster". Please advise on whether it is preferable to retain this Idea or create a new one.

This is unfortunately just not possible. Even though operators are installed per namespace, there are aspects of the operator install that are cluster scoped, when an operator is installed we are installing an extension to the Kubernetes API on the cluster, represented by a ClusterResourceDefintion (CRD).

To support multiple releases of MAS on a cluster we maintain a consistent fix-level across those releases to ensure any necessary compatibility updates are available in the CRD, because if you install MAS 8.10 and MAS 8.11 there is only one CRD, and it could be the one that came with MAS 8.10 or the one that came with MAS 8.11, so when we deliver a fix we have to know that the fix is applied across the board so that it guarantees the cluster-scoped resources that are part of the install are fixed, not just the instance-scoped resources. By providing our operator packages to a cluster in multiple packages we will not know which catalog's package owns the CRD, and depending which catalog you update you may only end up getting half the update.

Furthermore, OLM v1 is moving away from even supporting duplicate operator packages in different catalogs, so this is not a direction we would like to move MAS, or encourage customers to pursue: https://operator-framework.github.io/operator-controller/tutorials/install-extension/

If multiple catalogs are added to a cluster, you cannot specify a catalog when you install an extension.
OLM 1.0 requires that all of the extensions have unique bundle and package names for dependency resolution.
As a result, if two catalogs have an extension with the same name, the installation might fail or lead to an unintended outcome. For example, the first extension that matches might install successfully and finish without searching for a match in the second catalog.

Today, we offer the ability to pin the version of the operands to a specific level (spec.version), and the supported versions are listed in the status field (status.versions.supportedVersions), when using this it will cause the operand to remain at the chosen version even when the operator is updated. This allows for patch release differences across MAS instances on the same cluster, while maintaining parity in the controller managers that are installed. Although we designed this feature primarily to be used as a short term tool to facilitate rollback of a bad update or similar, this mechanism could be used to independently control the patch level of installed MAS instances. Doing so would place an extra burden on the team operating the MAS estate to control the specific versions in each MAS instance, in addition to the normal update processes.

I don't see the connection between maintaining a consistent patch level across instances and being able to have 8.10.11 and 8.10.12 running on the same cluster, and needing to "buy massive amounts of hardware", so I may be missing something in the idea here; feel free to provide more information if you feel this is the case.