Feature Overview

Integrate support for OLMv1 (ClusterExtension API, olm.operatorframework.io/v1) into the existing OperatorPolicy custom resource in Open Cluster Management (ACM). This will allow operator deployments via the new OLMv1 mechanism introduced in OpenShift 4.18, while maintaining current support for OLMv0 (Subscription-based operator deployment).

This enables users to continue leveraging policy-based automation without reverting to ConfigurationPolicy or managing multiple deployment strategies.

---

Goals

• Enable support for deploying operators via OLMv1 (ClusterExtension) using OperatorPolicy.

• Maintain backward compatibility with existing OLMv0 workflows (Subscription, InstallPlan, etc.).

• Avoid the need to switch to ConfigurationPolicy when targeting clusters running OCP 4.18+.

• Seamless experience for multi-cluster, multi-version OpenShift environments.

---

Requirements

 

---

Use Cases

Main Success Scenarios

• As a cluster administrator, I want to deploy OLMv1-style operators via OperatorPolicy to OCP 4.18+ clusters.

• As a platform engineer, I want to use a single policy type (OperatorPolicy) to manage both OLMv0 and OLMv1-based operator installations across a heterogeneous OpenShift fleet.

Alternate Flow/Scenarios

• If a cluster does not support OLMv1, the system should either:

• • Fallback automatically to OLMv0 style, or

• • Provide clear error messaging and suggest alternatives.

---

Questions to Answer

• Should OperatorPolicy detect and decide between OLMv0 and OLMv1 automatically, or should the user specify it?

• Should we support dual-mode policies (e.g., define both versions in one policy)?

• Will this require additional RBAC permissions or changes to the controller's scope?

• Will OLMv1 support all operators currently supported under OLMv0?

---

Out of Scope

• Supporting non-OLM operator installation mechanisms (e.g., raw manifests).

• Enhancements to ConfigurationPolicy to support OLMv1 (this feature is focused solely on OperatorPolicy).

• Deep validation or conversion of existing OLMv0 policies to OLMv1.

---

Background and Strategic Fit

Today, ACM’s OperatorPolicy supports operator installation using OLMv0 constructs (Subscription, InstallPlan, etc.). With OpenShift 4.18, Red Hat introduces OLMv1 and the ClusterExtension CR, offering a more Kubernetes-native and declarative experience.

As customers adopt OCP 4.18+, they expect ACM to support this natively. Without support in OperatorPolicy, users may need to fall back to ConfigurationPolicy or custom scripting — breaking uniformity and automation.

Supporting OLMv1 in OperatorPolicy aligns ACM with OpenShift platform evolution, improves user experience, and reduces fragmentation in operator deployment workflows.

---

Assumptions

• Clusters using OpenShift 4.18+ will have OLMv1 GA and ClusterExtension available.

• Users are already using OperatorPolicy with OLMv0, and want a seamless migration path.

• Not all operators will immediately support OLMv1 — mixed environments must be supported.

---

Customer Considerations

• Many customers rely on OperatorPolicy for GitOps and policy-driven workflows.

• Asking customers to rewrite policies or switch to ConfigurationPolicy for OLMv1 would create friction.

• Mixed-version OpenShift fleets are common in enterprises, requiring adaptive solutions.