Support transforming registry+v1 bundles to plain k8s bundles

[exdx]

The current operator ecosystem is built around the registry+v1 operator bundle format (which includes details like always including a CSV manifest under /manifests, bundle properties, additional installation information in the /metadata directory, etc). It has been in-use for over two years and is well defined and understood by the community.

The rukpak project is building out a new set of OLM APIs, that are clusterwide in scope, and the focus is on supporting a different bundle format from the beginning: a bundle containing a set of plain k8s yaml manifests. This bundle format is more declarative and intuitive for newer users, but is very different from the existing registry+v1 format. To avoid fragmenting the ecosystem and encourage adoption of the newer APIs, it would be ideal to provide tooling to convert a registry+v1 bundle to a plain k8s bundle. The tool could be a CLI tool as well as a library that rukpak provisioners can import and use.

[joelanford]

There's at least one complication I ran into around a general registry+v1 -> plain transformer: certificate generation and rotation for webhooks.

Registry+v1 bundles that include webhook configurations require certificates to be configured. OLM manages these certificates internally today. During the conversion process, something has to account for these certificates.

The two obvious options are:

1. Rely on cert-manager APIs (for plain manifest bundles that aren't converted from registry+v1 bundles, this seems like the obvious choice for bundle authors, so it seems like a reasonable choice for conversion)
2. Depend on the provisioner itself to provide the certificate generation/rotation logic (much like OLM does today)

Option 1 would mean:

• that we could build a fully offline conversion tool for bundle authors that want to convert existing registry+v1 content.
• potentially that a bundle could state "core.rukpak.io/registry+v1" for its class, and the corresponding bundle instance could state "core.rukpak.io/k8s" (or whatever we're calling it). in that case, we'd only need to build a bundle controller (and not a bundle instance controller) for the "core.rukpak.io/registry+v1" provisioner class

Option 2 would mean a full provisioner implementation since the bundle instance controller would need to handle the certificates.

[exdx]

Related to #396

[timflannagan]

Related to #449.

[awgreene]

#396 can be used as a starting point for someone interested in delivering this feature. #396 has a few post-merge comments that should be addressed in the PR submitted to master.

Marking this as a good first issue.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

[tylerslaton]

This relates heavily to a previous bundle conversion branch that we had. In order to close this issue out we should work to update the work done on it to the recent RukPak changes.

https://github.com/operator-framework/rukpak/tree/bundle-convert-package