Feature Overview

• The existing OLM concepts and on-disk formats around catalogs, packages, and channels are to be used as a basis for OLM 1.0 and its new set of APIs.

Goals

• Users of OLM 1.0 can leverage the existing catalog images that ship with OpenShift since 4.9 or newer (in the FBC format).
• Users of OLM 1.0 are enabled to use the OLM 1.0 APIs in parallel with the 0.x APIs on the same cluster with the same catalog image.
• Users of OLM 1.0 do not have to rebuild their existing catalogs into a new format if they are already using the FBC format.
• Users of OLM 1.0 do not have to re-learn OLM core packaging concepts. Operators still ship in a history of versions inside a channel, a collection of channels is known as a package
• OLM 1.0 allows users to leverage multiple references to catalogs at the cluster level to resolve installation requests, updates, and dependencies between extensions

Requirements

• OLM 1.0 APIs are going to be cluster-scoped. As such we need to bridge the current namespace-scoped catalog model.

Use Cases

Main Use Case:

• OLM 1.0 users (with necessary permissions) will be able to explore and discover operators from the current existing catalogs that are compatible with OLM 1.0’s new lifecycle model on their clusters.  
• There is an API where they can see the details of an operator, including its description, provided APIs, provider information, update channels, and the available versions within a channel for making an informed decision prior to the installation.
• OLM 1.0 users can still select from a range of available packages, release channels, and versions to install that come from a catalog image that ships in the FBC format
• OLM 1.0 users references potentially multiple catalogs in the cluster which add to a larger, flat set of extension for the resolution of installations, updates, and dependencies
• ("migration strategy" related) OLM 1.0 users can leverage the OpenShift default catalogs with the new APIs right after cluster installation without any additional configuration

Alternative Use Case:

• OLM 1.0 users can re-use their existing custom catalogs but may have to reference them in the cluster with another, cluster-scoped API

Definition of Done / Acceptance criteria

• all use cases discussed above are implemented
• the existing weighting of catalogs remains available
• the existing scoping of an installation request to a particular catalog remains available

Background, and strategic fit

This is part of a larger effort to re-design vital parts of the OLM APIs and conceptual models to fit the use case of OLM in managed service environments, GitOps-controlled infrastructure and restrictive self-managed deployments in Enterprise environments. You can learn more about it here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing

Documentation Considerations

• (“Operators > Understanding Operators > OLM” section) The way OLM 1.0 refers to existing FBC-formatted catalog images needs to be documented
• (“Operators > Administrator tasks” section) Users need to understand how catalog references are managed on the cluster when the operator management happens at the cluster scope
• (“Operators > Understanding Operators > OLM” section) Users need to understand how OLM 1.0 resolves installation, update, and dependencies when multiple catalogs are present, especially when candidates from multiple catalogs exist
• (“Operators > Administrator tasks” section) We expect some customers to use this feature to bring custom operators to the cluster.

• ("migration strategy" related) / (“Operators > Understanding Operators” section) The way OLM 1.0 picks up existing default catalogs in the namespaced OLM 0.x model needs to be documented
• ("migration strategy" related) / (“Operators > Understanding Operators” section)We expect customers to mainly use this feature implicitly when they use the OLM 1.0 APIs with pre-configured catalog references
•  ("migration strategy" related) / (“Operators > Understanding Operators” section) We expect a significant amount of customers to use this feature to bring mirrored catalogs onto the cluster