Feature Overview (aka. Goal Summary)  

• Initial Tech Preview of Next-Gen OLM UX: This ticket introduces the initial Tech Preview release of the next-generation OLM (OLM v1) user experience in the console.

• Unified Catalog UX: This ticket focuses on enabling a unified catalog UX in the console. This will allow customers to manage layered capabilities delivered through operators and partners' workloads, including OpenShift certified Helm charts, using the next-generation OLM (OLM v1) in the OpenShift console.

• In-Cluster Catalog Content Service: This is enabled through the novel in-cluster efficient catalog content service designed in OCPSTRAT-1655 and delivered in the 4.18 timeframe.

Goals (aka. expected user outcomes)

In essence, customers can: 

• discover collections of k8s extension/operator contents released in the FBC format with richer visibility into their release channels, versions, update graphs, and the deprecation information (if any) to make informed decisions about installation and/or update them.

• install a k8s extension/operator declaratively and potentially automate with GitOps to ensure predictable and reliable deployments.

• update a k8s extension/operator to a desired target version or keep it updated within a specific version range for security fixes without breaking changes.

• remove a k8s extension/operator declaratively and entirely including cleaning up its CRDs and other relevant on-cluster resources (with a way to opt out of this coming up in a later release). 

Requirements (aka. Acceptance Criteria):

1) Pre-installation:

• Both cluster-admins or non-privileged end-users can explore and discover the layered capabilities or workloads delivered by k8s extensions/operators or plain helm charts from a unified ecosystem catalog UI in the ‘Administrator Perspective’ in the console.

• Users can filter the available offerings based on the delivery mechanism/source type (i.e., operator-backed or plain helm charts), providers (i.e., from Red Hat or ISVs), valid subscriptions, infrastructure features, etc. 

• Users can discover all versions in all channels that an offering/package defines in a catalog, select a version from a channel, and see its detailed description, provided APIs, and other metadata before the installation.

2) Installation: 

• Users (who have access to OLM v1’s user facing ‘ClusterExtension’ API) using a ServiceAccount with sufficient permissions can install a k8s extension/operator with a desired target version or the latest version within a specific version range (from the associated channel) to get the latest security fixes.

• Users can see the recommended installation namespace if provided by the package authors for installation.

• Users get notified through error messages from the OLM API whenever two conflicting k8s extensions/operators (will be) owning the same API objects, i.e., no conflicting ownership, after triggering the installation.

• During the installation, users can see the installation progress reported from the ‘ClusterExtension’ API object.

• After installed, users (who have access to OLM v1’s user-facing ‘ClusterExtension’ API) can see can access the metadata of the installed k8s extension/operator to see essential information such as its provided APIs, example YAMLs of its provided APIs, descriptions, infrastructure features, valid subscriptions, etc.

3) Update:

• Users (who have access to OLM v1’s user facing ‘ClusterExtension’ API) can see what updates are available for their k8s extension/operators in the form of immediate target versions and the associated update channels.

• Users can trigger the update of a k8s extension/operator with a desired target version or the latest version within a specific version range (from the associated channel) to get the latest security fixes.

• Users get notified through error messages whenever a k8s extension/operator is prevented from updating to a newer version that has a backward incompatible CustomResourceDefinition (CRD) that will cause workload or k8s extension/operator breakage.

• During OpenShift cluster update, users get Informed when installed k8s extensions/operators do not support the next OpenShift version (when annotated by the package author/provider).  Customers must update those k8s extensions/operators to a newer/compatible version before OLM unblocks the OpenShift cluster update.

• During the update, users can see the progress reported from the ‘ClusterExtension’ API object.

4) Uninstallation/Deletion:

• Users are made aware of OLM v1 by default cleanly remove an installed k8s extension/operator including deleting CustomResourceDefinitions (CRDs), custom resource objects (CRs) of the CRDs, and other relevant resources to revert the cluster to its original state before the installation.

• Users can see a list of resources that are relevant to the installed k8s extension/operator they are about to remove and then explicitly confirm the deletion.

Questions to Answer (Optional):

• What impact will the console's "perspective consolidation" initiative have on this?

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Background

Our customers will experience a streamlined approach to managing layered capabilities and workloads delivered through operators, operators packaged in Helm charts, or even plain Helm charts.  The next generation OLM will power this central distribution mechanism within the OpenShift in the future. 

Customers will be able to explore and discover the layered capabilities or workloads, and then install those offerings and make them available on their OpenShift clusters.  Similar to the experience with the current OperatorHub, customers will be able to sort and filter the available offerings based on the delivery mechanism (i.e., operator-backed or plain helm charts), source type (i.e., from Red Hat or ISVs), valid subscriptions, infrastructure features, etc.  Once click on a specific offering, they see the details which include the description, usage, and requirements of the offering, the provided services in APIs, and the rest of the relevant metadata for making the decisions.  

The next-gen OLM aims to unify workload management.  This includes operators packaged for current OLM, operators packaged in Helm charts, and even plain Helm charts for workloads.  We want to leverage the current support for managing plain Helm charts within OpenShift and the console for leveraging our investment over the years. 

Documentation Considerations

Refer to the “Documentation Considerations” section of the OLM v1 GA feature.

Relevant documents

• Next-gen OLM UX: Unifying workload management
• Next-gen OLM UX: Unifying workload management
• Operator Framework F2F - PM Session
• PRD OLM 1.0
• OLM F2F Discussion - Roadmap
• Post F2F Roadmap