Epic Goal

• Enable generic bundle API (rukpak) to better support optional platform Operators (Composable OpenShift) in the long run

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. 

As “Composable OpenShift” is essential to the OpenShift BU, it's critical for SDK/OLM teams to work together as one team to make sure the success of the generic bundle API (rukpak).

Acceptance Criteria

• Working closely with the rukpak WG with the OLM team and upstream community to contribute to the upstream tickets in the OCP 4.12 release timeframe

Previous Work:

1. bundle conversion tool from `registry+v1` to `plain+v0` bundle

Future Work (out of scope for now):

• 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