-
Feature
-
Resolution: Done
-
Major
-
None
-
Strategic Product Work
-
False
-
-
False
-
-
0% To Do, 0% In Progress, 100% Done
-
0
-
Program Call
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-widesingletons, 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
| 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 | |
| Constraints need to be evaluated before the installation is attempted | See feature: OLM 1.0 - Installation and Update preflight checks (F6) | YES |
| 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 | YES | |
| The absence of the desired version is interpreted as the latest version | See Brief: Initial upgrade support | 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 | NO |
| The absence of the desired channel is interpreted as the default channel | NO |
|
| Installation requests can be made against catalogs as well as in the form of a single bundle image | 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 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
Relevant upstream CNCF OLM engineering brief(s):
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.
- split from
-
-
- New
-
- split to
-
-
- Closed
-
