Goals

Enable OLM integration for optional platform Operators so they can move away from OCP core payload to be released and managed by OLM.

Why is this important?

Generic bundle API (rukpak) is the future of the bundle provisioner API in OLM. It opens the door for OLM in supporting other package formats, e.g. Helm chart or simply arbitrary Kubernetes manifests, which (the latter) closely resemble the Platform Operators predominantly see in the downstream managed by the CVO.

To support “Composable OpenShift”, delivering toolings or technologies for enabling next-gen generic bundle provisioner will help change optional platform Operators from being managed by CVO and shipped in the core OCP payload to being lifecycled by the OLM and released in a faster release cadence. 

Thereby, OCP can:

• shrink the size of the core release payload, making build, distribution, and mirroring takes less time and space

• pave the way for having some of those components disabled by default

• enable OCP BU to release those platform components on their own schedule (un-tie them with OCP releases) 

Deliverables

• Support optional Platform Operators to package their manifests into a bundle format that can be managed by the OLM
  • if using `registry+v1` bundles, support packaging in `registry+v1` bundles
  • if using `plain+v0` bundles, support packaging in `registry+v1` bundles and can later be converted to `plain+v0` bundles, or directly packing in `plain+v0` bundles

• Support OLM to deliver "generic OLM bundle API" (rukpak) for `plain+v0` bundles

• `bundle generate`, `bundle validate`, and `run bundle/bundle-upgrade` can be easily reusable among different SDK language plugins.