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

[Phase 1 MVP/Tech Preview] OLM 1.0 - Extension Installation (F7)

XMLWordPrintable

    • BU Product Work
    • False
    • Hide

      None

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

      Feature Overview

      • Note: This feature is aimed to track the progress of Phase 1 MVP scope for the OLM 1.0
        • i.e., "IsMVP: YES" in the table of Functional Requirements.
        • Specifically, the Installation in 4.14 release does not support "evaluating constraints before the installation":
          OCPBU-108 OLM 1.0 - Installation and Update preflight checks (F6)

       

      • OLM 1.0 needs a declarative way to install extensions either from a catalog of extensions or directly from an OCI image.
      • Should the installation attempt fail due to unfilled requirements, constraints, preflight checks or dependencies there needs to be an option to force the install.
      • Extensions are cluster-wide singletons, thus they can only be installed once in the cluster and are managed at cluster-scope.

      Goals

      • Simplify the process and interaction points for users of OLM 1.0 to install a specific version extension down to a single, declarative API call at the cluster level
      • Provide a GitOps- and automation-friendly way to install extensions on a cluster
      • Retain the ability to install extensions from catalogs of extensions known as catalogs (OCPBU-107 OLM 1.0 - Extension Catalogs (F1))
      • Provide the ability for accelerated inner loops for extension developers by allowing them to install an extension from a standalone bundle as part in the form of an OCI image as opposed to a catalog

      Requirements

       

      Requirement Notes isMvp?
      Installation of extensions needs to be possible with a single declarative API call   YES
      Failed installations should not leave resources behind beyond the object representing the cluster-scoped extension that was attempted to be installed   YES
      The version and release channel that the extension should be installed from need to be specified   YES
      The absence of the desired version is interpreted as the latest version   YES
      Installations should be processed independently of the update policy of the extension require no additional approval to install an extension with update policy set to manual
      “Update policy” is blocked on progress in OCPBU-614      		 YES NO
      Absence of the desired channel is interpreted as the default channel “default channel” (or the entire default channel concept) is blocked on progress in OCPBU-614 YES
      NO
      Installation requests can be made against catalogs as well as in the form of a single bundle image (Operator API currently only supports dereferencing from catalogs. Currently rukpak would need to be used directly to install a single bundle image) YES
      NO
      Constraints need to be evaluated before the installation is attempted OCPBU-108 OLM 1.0 - Installation and Update preflight checks (F6) YES
      NO
      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:

      • A cluster-admin installs an extension by referencing an entry from a catalog by specifying catalog name, extension name and optionally name of the release channel and desired version
        • Note: (specifying a catalog is currently not supported; the requirement that a catalog must be specified in the Operator API needs further discussion)
      • A cluster admin installs an extension by referencing an OCI image containing a single bundle, specifying a name, channel and desired version is not required

      Definition of Done / Acceptance criteria

      • all use cases discussed above are implemented
      • all requirements marked as MVP are met
      • custom controllers and CRDs (colloquially called operators) should be capable of being installed on the cluster

      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

      Assumptions

      • Extensions are handled at the cluster scope level

      Documentation Considerations

      • A user needs to understand how to leverage this functionality in order to add extensions at the cluster level
      • The concept of Kubernetes RBAC and its effect on privilege escalation through OLM needs to be explained to the user

       
       
       

       

              DanielMesser Daniel Messer
              DanielMesser Daniel Messer
              Jian Zhang Jian Zhang
              Matthew Werner Matthew Werner
              Joe Lanford Joe Lanford
              Senthamilarasu S Senthamilarasu S
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: