Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-337

[Phase 1 MVP/Tech Preview] OLM 1.0 - Extension Catalogs (F1)


    • False
    • Hide


    • False
    • OCPSTRAT-27OLM V1: Operators, Operator Lifecycle Management, and Operator Hub
    • 0% To Do, 42% In Progress, 58% Done
    • 0
    • Program Call

      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.


      • 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 can enable OLM 1.0 APIs and create API object(s) 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 channel is known as a package.


      • OLM 1.0 APIs are going to be cluster-scoped. As such we need to bridge the current namespace-scoped catalog model.
      Requirement Notes isMvp?
      A cluster-scoped catalog representation must exist   YES
      CI - MUST be running successfully with test automation This is a requirement for ALL features. YES
      Release Technical Enablement Provide necessary release enablement details and documents. YES

      Use Cases

      Main Use Case:

      • OLM 1.0 users can leverage the OpenShift default catalogs with the new APIs with easy configurations
      • 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

      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

      • the way OLM 1.0 refers to existing FBC-formatted catalog images needs to be documented.
        • 3 YAML samples in the doc:
          • Catalog YAML references Red Hat catalog
          • Catalog YAML references Certified catalog
          • Catalog YAML reference Community catalog
      • users need to understand how catalog references are managed on the cluster when the operator management happens at the cluster scope
      • users need to understand how OLM 1.0 resolves installation
      • we expect some customers to use this feature to bring custom operators to the cluster

            DanielMesser Daniel Messer
            DanielMesser Daniel Messer
            Jian Zhang Jian Zhang
            Matthew Werner Matthew Werner
            Joe Lanford Joe Lanford
            Senthamilarasu S Senthamilarasu S
            0 Vote for this issue
            8 Start watching this issue