Feature Overview

• 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 installation.

• 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 (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

Use Cases

Main use case:

• A cluster-admin installs an extension by referencing an entry from a catalog by specifying the catalog name, extension name, and optionally name of the release channel and desired version.
• 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 have been 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

• (“Operators > Administrator tasks” section) A user needs to understand how to leverage this functionality in order to add extensions at the cluster level in different use cases, e.g.,
  • The name of the release channel and desired version are optional but can be used to easily designate a desired version to install or update toward. 
  • set operator updates to be applied automatically but bound to patch releases

• (“Operators > Administrator tasks” section) The concept of Kubernetes RBAC and its effect on privilege escalation through OLM needs to be explained to the user.