What is the best practice to upgrade operator nightly builds using OLM?

[fantapsody]

Type of question

community best practices

Question

I'm working on an project to build operators, and trying to use OLM to manage the lifecycle of the operators. I followed the documents to create images of bundles and bundle index with opm, and created a catalogsource based on the image to deploy the operator. It works well for the installation of the operators, and I would like to use OLM to upgrade operators in our test clusters automatically every day with nightly builds.

However, I haven't figured out how to do it in the most efficient way with minimal operational efforts. Do I need to maintain a list of all the nightly builds in the index, and always create a new index image containing the bundle of the snapshot version based on the previous one? Is it possible to always create a new index image with the snapshot bundle from scratch to make the nightly build "stateless", and upgrade operators automatically?

Thanks!

Environment

• operator-lifecycle-manager version:

0.14.1

• Kubernetes version information:

1.15.7

• Kubernetes cluster kind:

GCP

[ecordell]

Great question, @fantapsody - we're trying to improve our docs over at the olm book and this would be a great case study to include.

I think the specifics of how we get you to "minimal operational overhead" may depend on how you are building / etc. Any details you can share would help us help you 😄

In 1.14.1 we added CatalogSource polling for image types. See the docs here.

One way you could do what you're trying to do is by maintaining a moving tag for your index image (i.e. quay.io/my/catalog:nightly). When you have a new nightly build available, you can pull the existing nightly tag, run opm index add to add the nightly bundle to your index, and update the nightly tag to point to index you just pushed. (I would also tag these by git sha or time so that you have a record).

Then a CatalogSource pointing to the tag with an update policy will poll for updates and roll out changes when your index is updated.

[fantapsody]

Thanks! @ecordell

I have tried to do as you suggested, and in this case I have to get the head version of the channel, and set spec.replaces in CSV correctly. And in order to do so, I have to run opm export to save the manifests to local disk and extract the head version in the package file. It is workable, while I also would like to know if there is a simpler way to do that.

On the other hand, there may be tens of or hundreds of versions in the catalog source image if we release snapshot builds frequently, would that be a problem? And should we use a separate index image or a separate channel?

CatalogSource polling seems to be promising and I also have tried it. One thing that bothers is that if I set the interval to 1 minutes, it may take up to 15 minutes to do another check, is this by design?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.