This repository has been archived by the owner on Aug 2, 2023. It is now read-only.
Investigate move to opm
for building operator registry
#685
Labels
We currently use
operator-registry
tools to build an operator registry (catalog) containing the Kabanero operator, and some other operators that we copy from community-operators. To build the registry, we have a directory of metadata, and we point a Dockerfile at this directory and out pops a container which contains a registry that OLM can query and install operators from.The
operator-registry
is transitioning to a new tool calledopm
which creates Operator Bundles, which in turn are consumed by OLM. See:https://github.com/operator-framework/operator-registry/blob/master/docs/design/operator-bundle.md
It looks like you build a specific version of an operator into a non-executable container image, using
opm
. Then you pointopm
at a set of these and create an index, which creates another container image that can be consumed by OLM in the traditional way (can be put in a catalogsource).We need to investigate this new format and how we can start using it in Kabanero. OCP version 4.3 is using OLM version 0.13.0, which mentions bundles. OLM 0.14.0 includes more PRs that use bundles, but there is still very little documentation around how to configure OLM to use a bundle. We are also starting to see signs in
operator-sdk
, that it is no longer going to produce the manifests in the old way, only the newer bundle way (see breaking changes in https://github.com/operator-framework/operator-sdk/releases/tag/v0.17.0). Now granted we don't take advantage of any of the operator-sdk tools that generate the CSV, but this can be taken as a statement of direction regardless.It may be that OCP 4.4 contains enough of this support that we can transition to using
opm
at that time. Or we may need to wait for OCP 4.5.The text was updated successfully, but these errors were encountered: