Skip to content
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

Open
kaczyns opened this issue May 5, 2020 · 2 comments
Open

Investigate move to opm for building operator registry #685

kaczyns opened this issue May 5, 2020 · 2 comments
Labels

Comments

@kaczyns
Copy link
Member

kaczyns commented May 5, 2020

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 called opm 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 point opm 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.

@kaczyns kaczyns added the design label May 5, 2020
@kaczyns
Copy link
Member Author

kaczyns commented May 7, 2020

@dacleyra
Copy link
Collaborator

OCP 4.3 uses OLM release-4.3 and does not have the bundle support
OCP 4.4 uses OLM release-4.4 and appears to have the bundle support

oc -n openshift-operator-lifecycle-manager describe pod -l app=olm-operator | grep RELEASE_VERSION

https://github.com/operator-framework/operator-lifecycle-manager/blob/release-4.3/doc/design/resolving-bundle-images.md
https://github.com/operator-framework/operator-lifecycle-manager/blob/release-4.4/doc/design/resolving-bundle-images.md

Moving to bundles would appear to require OCP 4.4

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants