Background and why for OLMv1

The Operator Framework team has been focused on designing and building the next generation of OLM, OLM v1.

Leveraging insights gained from OCP 4 and customer feedback, OLM v1 is a significant overhaul designed to address the challenges we've observed.  It aims to enable a better future for managing operators and other extensive workloads on OpenShift, with fully declarative, GitOps-friendly workflows, complete control over desired update paths, and simplified top-level user-facing APIs.

While the initial GA release of OLM v1 will support a limited set of operators, we aim to ensure interoperability with the broader operator ecosystem, particularly starting from operators that meet the specified criteria due to the current limitations.

We want to achieve this by integrating "Operator deployment/upgrade tests against OLM v1" into Red Hat's release pipelines.  This will enable us to proactively identify and address interoperability issues between OLM v1 and existing operators, streamlining the adoption of OLM v1 across the operator ecosystem, while maintaining a unified release track for Red Hat operator teams.

OLM v1 is GA from OCP 4.18, and will support webhooks in 4.21. OLM v0 is expected to continue to be supported at least until OCP 5.x is released (Oct 26).

Some notable changes:

• Installation - No longer performed through the UI, and it is done by CLI using a ClusterExtension, ClusterRoleBinding, and a serviceAccount.
• Upgrades - Defined in the ClusterExtension on how to perform upgrades (see references below), and includes a Custom Resource Definition (CRD) Upgrade Safety https://operator-framework.github.io/operator-controller/concepts/crd-upgrade-safety/ 

How to test it?

Follow the steps at How do I verify a bundle with OLMv1? and use the following MDR values for the manifest template:

• <packageName>=machine-deletion-remediation
• <installNamespace>=machine-deletion-remediation-system
• Run ` oc apply -f olmv1/mdr-olmv1-manifest.yaml `

References:

• https://operator-framework.github.io/operator-controller/project/olmv1_design_decisions/ 
• operator upgrades (and changes)
  • upgrade support - https://operator-framework.github.io/operator-controller/concepts/upgrade-support/ 
  • Content resolution - https://operator-framework.github.io/operator-controller/concepts/controlling-catalog-selection 
  • channel upgrades - https://operator-framework.github.io/operator-controller/howto/how-to-channel-based-upgrades/
  • pin version - https://operator-framework.github.io/operator-controller/howto/how-to-pin-version/
  • version range - https://operator-framework.github.io/operator-controller/howto/how-to-version-range-upgrades/ or z stream upgrades https://operator-framework.github.io/operator-controller/howto/how-to-z-stream-upgrades/ 
  • version range symbols - https://operator-framework.github.io/operator-controller/concepts/version-ranges/