Feature Overview (aka. Goal Summary)  

This 4.18 ticket is the successor of OCPSTRAT-1589 (for 4.17) and focuses on a reduced scope compared to the broader Tech Preview outlined in OCPSTRAT-1327.

The console in the 4.18 Tech Preview release introduces the following new capabilities for managing Helm charts:

• Discover certified Helm charts: Explore a collection of OpenShift-certified Helm charts within the new "Ecosystem" catalog UI in the "Administrator Perspective."
• Install Helm charts: Easily install desired Helm charts from the "Ecosystem" section of the console.
• View installed helm charts: Manage and view a list of installed Helm charts within the "Ecosystem" section.

Internal goal (Non-user-facing):

• Efficient package property retrieval: Develop an in-cluster catalog content service to efficiently retrieve specific properties for operator packages and versions from the File-based Catalog (FBC).
• This paves the way for the expanded catalog discovery capability: If the in-cluster service is successfully implemented in the 4.18 milestone, users may be able to:
  • discover Kubernetes extension/operator content released in FBC format within the new "Ecosystem" catalog UI.
  • view and edit installed Kubernetes extension/operator objects using the built-in YAML editor.

Goals (aka. expected user outcomes)

• Pre-installation: 
  • Both cluster administrators and non-privileged end-users can discover OpenShift-certified Helm charts using the unified ecosystem catalog UI in the console's Administrator Perspective, sourcing from the existing OpenShift Helm charts Repository.
  • Users can filter available offerings by provider (Red Hat, ISV, community, etc) and other criteria in the new unified ecosystem catalog UI.

• Installation: 
  • Both cluster administrators and non-privileged end-users can install a certified Helm chart with a desired target version in the new "Ecosystem" UI section in the Administrator Perspective, similar to the experience in the Developer Perspective of the console.

• PostInstallation:- 
  • Users can view a list of installed Helm charts and easily read, update, and delete them using the console.

• Internal Goal: Efficient catalog content service 
  • Develop an in-cluster catalog content service to enable efficient retrieval of specific operator properties.  
  • This service will lay the groundwork for future enhancements, e.g.,

• • • Pre-installation:
      • Users can filter the offerings based on 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.
    • Installation: 
      • Users can see the recommended installation namespace if provided by the package authors for installation.
      • After installed, users (who have access to OLM v1's user-facing 'ClusterExtension' API) can see 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.
    • 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.
      • 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 with `olm.maxOpenShiftVersion` annotation).  Customers must update those k8s extensions/operators to a newer/compatible version before OLM unblocks the OpenShift cluster update. 
    • 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.

Requirements (aka. Acceptance Criteria):

All the expected user outcomes and the acceptance criteria in the engineering epics are covered.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Out of Scope

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

<your text here>

Background

This 4.18 ticket is the successor of OCPSTRAT-1589 (for 4.17) and focuses on a reduced scope compared to the broader Tech Preview outlined in OCPSTRAT-1327 .

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

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