Feature Overview

• Unprivileged tenants need to discover extensions available in a catalog for installation. 

• Users need to be able to discover all versions in all channels that an extension package defines in a catalog.  

• The privilege should be given at the discretion of the cluster administrator.

Goals

• Cluster admins can delegate the lifecycle decisions of extensions/Operators to "secondary admin" personas for their deeper knowledge of the particular service the extension offers and the audience that uses it.

• OLM 1.0 provides all version info/history in catalogs to users for installing or updating the extension so they can decide what gets installed, updated when available, or the lifecycle of this extension has ended.

Requirements

Use Cases

• OLM 1.0 users can see all available extensions/Operators packaged in a catalog.

• OLM 1.0 users can see all channels of an extension/Operator packaged in a catalog.

• OLM 1.0 users can see all versions in a channel from an extension/Operator available for installation in a catalog.

• OLM 1.0 privileged users can delegate catalog discovery to unprivileged tenants who have a deeper knowledge of the extensions/Operators to decide which version/channel of the extensions should be installed in the clusters.

Definition of Done / Acceptance criteria

• all use cases discussed above are implemented and meet the requirements.

Background, and strategic fit

The primary goal of administrator types of OLM users is to make the platform useful to tenants and give them the required freedom and functionality they need.  

For the cluster-admin type of users, they expect OLM to:

• handle deployment and updates (including security) of these extensions/Operators, but they do not want to be involved every time this needs to happen because a tenant would like to leverage a service provided by an extension. 
• warn the administrators if clusters' stability is endangered due to installed extensions/Operators.
• and equally importantly, to provide a way to control and grant a set of their tenants to pick and choose from available extensions/Operators to install and consume their services. 

In some customer organizations (the same for Red Hat's own managed service group), a secondary administrative persona exists to take care of the lifecycle of a single (or multiple) cluster extension because of the deeper knowledge of the particular service the extension offers and the audience that uses it. e.g. Service Mesh. 

They assume SRE-like responsibilities for the services provided by the extensions/Operators. Therefore, they:

• decide which version of the extension is running on the cluster and when it's time to upgrade or for maintenance.
• need the version history of the extension to decide what gets installed, updated when available, or the lifecycle of this extension has ended.
• needs a way to delegate the lifecycle of a single (or multiple) cluster extension further to the users when they see fit. 

Learn more about this OLM 1.0 feature (F2):

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 privileged users can grant unprivileged users catalog discovery needs to be documented (in the context of "Administrator tasks").

• The way users can see all the available extensions/Operators packaged in a catalog needs to be documented (in the context of "Administrator tasks").

• The way users can see all the channels of an extension/Operator packaged in a catalog needs to be documented (in the context of "Administrator tasks").

• The way users can see all versions in a channel from an extension/Operator available for installation in a catalog needs to be documented (in the context of "Administrator tasks").