Feature Overview (aka. Goal Summary)  

The next-gen OLM, OLM v1, as a HyperShift control plane component, runs within a dedicated namespace on the hosted cluster.

Goals (aka. expected user outcomes)

OLM v1, as a HyperShift control plane component, aligns with HyperShift's goal of streamlining cluster management.  By separating control plane components from worker nodes, HyperShift enables worker nodes to focus solely on running workloads.

By combining HyperShift and OLM v1, customers can reap the benefits of both.

HyperShift benefits:

• Developer focus: Developers can concentrate on building applications without worrying about underlying infrastructure.
• Cluster-admin focus: Cluster admins can focus on managing the overall cluster and optimizing resource allocation.

OLM v1 benefits:

• Simplified and standardized APIs: Customers can automate declarative operations through GitOps or Zero-Touch Provisioning (ZTP) workflows, reducing the risk of human error.
• Enhanced package support: Customers can manage both operators and Helm charts (in the future) with a consistent experience, regardless of packaging format, providing greater flexibility.

Background

In a standalone OpenShift cluster, the control plane and worker nodes are typically co-located.

HyperShift, however, divides a cluster into a hosted control plane and worker nodes.  The control plane, often residing on a dedicated management cluster, and the worker nodes together form a guest cluster.

Each HyperShift cluster's control plane is assigned a dedicated namespace to host its pods, including kube-apiserver, scheduler, MCO, and the classic OLM (OLM v0).

The next-generation OLM, OLM v1, which was released as GA in OCP 4.18, will run as a component of the HyperShift control plane.  This aligns with HyperShift's goal of helping customers reduce costs, focus on workloads, and minimize human error.

Requirements (aka. Acceptance Criteria):

Based on the existing designs and work completed in OCPSTRAT-582, here are the essential requirements for enabling OLM v1 in HyperShift:

• Control plane integration: OLM v1 is integrated as a core component of the HyperShift control plane, deployed on the hosted cluster.

• Namespace isolation: OLM v1 operates within a dedicated namespace on the HyperShift hosted cluster, ensuring isolation from other system components.

• Inter-cluster communication: OLM v1 can communicate with components on both the host and guest clusters.

• Operator deployment and management: OLM v1 provides mechanisms (e.g., node selectors) to deploy and manage operators on both the control plane (host cluster) and worker nodes (guest clusters).

• Catalog management: OLM v1 can access and manage catalogs from both the host cluster (for Red Hat-provided default catalogs) and guest clusters (for customer-created custom catalogs).

• Resource efficiency: OLM v1 is optimized to use minimal resources on the hosted cluster.

Questions to Answer:

• Version skew between the host and guest cluster: Given potential version skew between host and guest clusters, how does OLM v1 handle operator upgrades based on compatibility constraints? 

Documentation Considerations

• OLM v1 in HyperShift: Introduce how OLM v1 integrates into the HyperShift architecture, its role as a control plane component, and its interactions between host and guest clusters.

• Operator deployment: Introduce how to control the deployment of operators to either host or guest clusters.

• Catalog management: Introduce how to manage operator catalogs, including creating custom catalogs and utilizing Red Hat-provided catalogs.