1. Proposed title of this feature request

Production-ready operator version pinning per cluster with shared registry support in OpenShift 4.18 (OLM v0/v1)

2. What is the nature and description of the request?

We are running Red Hat OpenShift Container Platform 4.18 in an air-gapped environment using a single mirrored registry shared across three clusters (Test, OTA, Production).

We require the ability to:

• Pin a specific operator version per cluster

• Promote versions in a controlled manner (Test → OTA → Production)

• Prevent automatic upgrades when newer bundles are mirrored into the shared registry

Current behavior:

• Using OLM v0 with startingCSV and Manual InstallPlan does not guarantee version pinning.

• When newer operator bundles are present in the shared catalog, OLM upgrades the operator even if startingCSV is defined.

• This makes controlled lifecycle management impossible in a multi-cluster shared registry architecture.

We investigated OLM v1 / Cluster Extensions, as recommended in documentation. However:

• In 4.18, OLM v1 operators are not visible in the console.

• Console integration appears only in 4.21 as Tech Preview.

• Tech Preview is not supported for production use.

• Some Red Hat operators are not fully compatible with current OLM v1 limitations (AllNamespaces restrictions, webhook constraints).

Therefore, there is currently no supported production mechanism in 4.18 to enforce strict operator version pinning per cluster while using a single mirrored registry.

We request:

• A supported method to strictly pin operator versions per cluster in 4.18
  OR

• Production-ready OLM v1 / Cluster Extensions with console support
  OR

• Official supported guidance for enterprise operator promotion workflows with a shared registry

3. Why does the customer need this? (List the business requirements here)

• Controlled lifecycle management (LCM) is mandatory for production.

• Operators must be promoted progressively:

• • Weekly updates tested in Test

• • Then OTA

• • Then Production

• Production must never auto-upgrade to an untested version.

• All clusters are GitOps-managed; versions must be declarative and deterministic.

• Customers do not have CLI access in production and rely on the console.

• Enterprise environments require deterministic version control.

• Using separate registries per cluster is operationally undesirable and increases complexity.

• Production rollout is currently blocked due to inability to enforce version control.

This is a critical requirement for delivering a production-grade OpenShift platform.

4. List any affected packages or components.

• Red Hat OpenShift Container Platform 4.18

• OLM v0 (Operator Lifecycle Manager)

• OLM v1 / Cluster Extensions

• OperatorHub / Console integration

• Subscription / InstallPlan behavior

• Mirrored catalog / air-gapped registry architecture

Affected operators (examples observed during testing):

• Red Hat OpenShift Logging Operator

• Red Hat OpenShift Kubernetes Compatibility Operator

• Loki Operator