Epic Goal

Design delivery mechanism of platform operators

Why is this important?

The goal of Composable Openshift] is to provide a way for Openshift customers to choose the operators they want to include in their installation of Openshift. For customers to choose operators to include with the installation, there needs to be curated catalogs where customers can select the operators from. These catalog must make the operator packages available on cluster during cluster bootstrap, for components like rukpak+deppy to help install/lifecycle operators from.

At present, OLM implements the concept of catalogs via the CatalogSource CRD and the controller that reconciles it. However

1. The CatalogSource CRs are namespace-scoped, with additional information hardcoded to make some CRs behave as if they were cluster-scoped (eg "all Catalogs in the openshfit-marketplace are "global"), to support features like namespace-scoped dependency resolution of packages to facilitate multi-tenancy. This is at odds with OLM v1, where operators and their dependencies installed are cluster-scoped. Therefore, porting over the existing concept of namespace-scoped catalogs only introduces additional (unnecessary) costly complexities in OLM v1

1. The implementation of CatalogSource has encountered multiple sources of high CPU/memory consumptions, with several patches only getting it to a state where currently it "only" experiences CPU/memory consumption spikes (instead of constant exaggerated consumption). In order for Openshift to deliver these catalogs of operators on cluster with a goal of reducing the cost of running the control plane, the catalogs themselves must not be the source of high cost for the customers.

Therefore, there needs to be a way for these platform operators to be packaged and delivered on cluster for composable Openshift installations, in a manner that's compatible with OLM v1, while being efficient in executing the delivery. 

Additionally, the existing concept of Operator Catalogs needs to be extended to components built outside of the openshift payload, so that customers can choose to include these components to be part of/and lifecycled via OLM v1 components, as part of their installation. 

Scenarios

1. As an Openshift customer, I want to select a list of operators I want to include as part of my Openshift installation, from catalogs of curated, vetted operators. I want this to be achieved in a way that incurs minimal control-plane cost. 

1. As an author of a Catalog, I want a mechanism to deliver the list of operator I have curated and vetted, so that Openshift customers can use my catalog to select operators they want installed/lifecycled as part of their Openshift installation. I also want to be able to continually make newer versions of the operators I've packaged available to customer clusters, when authors of those operators release newer version of their operators/patches etc 

1. As an operator author, I want the ability to include my operator in catalogs being built by multiple authors, so that my operator can be made available for customers to include as a part of their Openshift installation. 

1. As cluster admin, for the components installed during installation of Openshift, I want newer versions of those components to be made available for upgrade as and when they're released.   

Acceptance Criteria

• Design doc outlining package delivery mechanism for platform operators 
• Prototype to encompass discussions/outcomes of the design doc

Dependencies (internal and external)

1. Platform Operators: There needs to be way to create a catalog of Platform Operators   
2. Deppy: Deppy needs indexes (catalogs) to be able query operator dependency/upgrade etc metadata from for resolving the dependencies of platform operators. 

Previous Work (Optional):

1. N/A

Open questions::

1. N/A

Done Checklist

• Design doc - https://hackmd.io/@of-olm/B1cMe1kHj
• *Follow up implementation epic/s https://issues.redhat.com/browse/OPECO-2639*