- 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-widesingletons, thus they can only be installed once in the cluster and are managed at cluster-scope.
- 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-107OLM 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
|Installation of extensions needs to be possible with a single declarative API call
|Failed installations should not leave resources behind beyond the object representing the cluster-scoped extension that was attempted to be installed
|The version and release channel that the extension should be installed from need to be specified
|The absence of the desired version is interpreted as the latest version
|“default channel” (or the entire default channel concept) is blocked on progress in
|(Operator API currently only supports dereferencing from catalogs. Currently rukpak would need to be used directly to install a single bundle image)
|OCPBU-108 OLM 1.0 - Installation and Update preflight checks (F6)
|CI - MUST be running successfully with test automation
|This is a requirement for ALL features.
|Release Technical Enablement
|Provide necessary release enablement details and documents.
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
- 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
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
- Extensions are handled at the cluster scope level
- 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