Support Operator Lifecycle Manager (OLM) registry+v1 bundles
Opened this issue · 3 comments
Describe the problem/challenge you have
The Operator Lifecycle Manager (OLM) is a project that aims to simplify lifecycle management of Kubernetes-native applications ("operators") and provide additional guardrails to prevent actions that can unintentionally or accidentally result in misconfigurations or data loss.
There is a large collection of operators that work with OLM. Many are viewable at https://operatorhub.io. OLM has a custom packaging format called registry+v1 that is an OCI image with a specific directory layout that OLM expects.
We are currently investigating using parts of the Carvel suite in our next major version of OLM, "v1", currently in development. kapp-controller is of particular interest. We'd like to use it to manage the content OLM applies to clusters, but kapp-controller doesn't currently support OLM's registry+v1 format.
Describe the solution you'd like
Add support for OLM's registry+v1 format as a "templating" step. This would take the contents of a .spec.fetch.image that points at an OLM registry+v1 image and process them in such a way that the .spec.deploy.kapp step can apply them to the cluster correctly.
Anything else you would like to add:
[Additional information that will assist in solving the issue.]
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.
@joaopapereira @praveenrewar
Please triage this.
Proposal to discuss the intended changes: https://docs.google.com/document/d/1ROxnv0ttzDGgjI_fIzdQAg0tcoefdcjVwpdM6LZyknE/edit
This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response.