Deploying your operator with OLM

The Operator Lifecycle Manager (OLM) provides a declarative way to install, manage and upgrade operators on Kubernetes clusters. How exactly this is accomplished is outside of the scope of this documentation and we recommend reading the OLM documentation.

That said, among the core tasks that are required to deploy your operator using OLM, the bundle-generator extension will facilitate the first two steps: generating the operator manifests and the associated bundle, as detailed below.

Requirements

Make sure you have installed the opm command tool and are connected to a Kubernetes cluster on which OLM is installed.

Generate the Operator image and bundle manifests

Quarkus provides several extensions to build the container image. For example, the Joke sample uses the Quarkus Jib container image extension to build the image. So, you first need to configure one of these extensions as you prefer. Then, you need to add the quarkus-operator-sdk-bundle-generator extension to your project:

<dependency>
    <groupId>io.quarkiverse.operatorsdk</groupId>
    <artifactId>quarkus-operator-sdk-bundle-generator</artifactId>
    <version>{project-version}</version>
</dependency>

This extension generates the Operator bundle manifests in the target/bundle directory.

Finally, to generate the operator image and the bundle manifests at once, you simply need to run the next Maven command:

mvn clean package -Dquarkus.container-image.build=true \
    -Dquarkus.container-image.push=true \
    -Dquarkus.container-image.registry=<your container registry. Example: quay.io> \
    -Dquarkus.container-image.group=<your container registry namespace> \
    -Dquarkus.kubernetes.namespace=<the kubernetes namespace where you will deploy the operator> \
    -Dquarkus.operator-sdk.bundle.channels=<the list of channels that bundle image belongs to>

For example, if we want to name the package my-operator and use the alpha channels, we would need to append the property -Dquarkus.operator-sdk.bundle.channels=alpha. The bundle name needs to be provided via the bundleName field, which would here take the my-operator value, of the @CSVMetadata annotation on your reconciler.

Find more information about channels and packages here.

If you’re using an insecure container registry, you’ll also need to append the next property to the Maven command -Dquarkus.container-image.insecure=true.

By default, the bundle generator disables outputting the application’s version as part of the manifests' selectors (equivalent to setting quarkus.kubernetes.add-version-to-label-selectors to false). This is done make updating your operator simpler. If, for some reason, you need that label to be added to the selectors, just set the property to true.

Controlling manifests metadata with CSVMetadata

While the extension attempts to infer a lot of the required information from your project itself and it is possible to generate valid bundles without providing extra information, it might still be useful or needed to specify additional metadata to help the generation process or provide data that cannot be inferred.

This is accomplished is using the io.quarkiverse.operatorsdk.annotations.CSVMetadata and its associated annotations from the quarkus-operator-sdk-annotations module. CSVMetadata is meant to annotate your reconciler instances.

By default, manifests for all reconcilers in a given operator will be generated as part of the same bundle, using a name automatically inferred from the project’s name. It is, however, possible to split the reconcilers among several bundles by assigning reconcilers to different bundle names. One bundle will be created per specified bundle name. To associate a reconciler with a bundle name, you need to put the shared metadata (in the form of CSVMetadata annotation) on a class implementing the io.quarkiverse.operatorsdk.annotations.SharedCSVMetadata marker interface, specifying the desired bundle name on the associated CSVMetadata annotation. All reconcilers annotated with CSVMetadata using the same name as one of the SharedCSVMetadata classes will be assigned to the same bundle and share the associated metadata. Any value specified on CSVMetadata annotations that designate a reconciler as sharing metadata coming from a SharedCSVMetadata source will be ignored.

You can see this behavior in action in the tests of the quarkus-operator-sdk-bundle-generator-deployment module.

Note: If you provide a SharedCSVMetadata implementation without specifying a bundle name, then the specified metadata will be shared among all reconcilers that don’t specify an explicit bundle name.

Validating the generated bundle

It is recommended that you validate your bundle before proceeding further. The recommended way to do so is to run the following command:

operator-sdk bundle validate  target/bundle/<your operator name> --select-optional suite=operatorframework

Build the Operator Bundle image

An Operator Bundle is a container image that stores Kubernetes manifests and metadata associated with an operator. You can find more information about this here. In the previous step, we generated the bundle manifests in target/bundle which includes a ready-to-use target/bundle/bundle.Dockerfile Dockerfile that you can use for this step, according to the OLM instructions to create bundle images.

Other OLM tasks

Once the bundle image is generated, you can then proceed with creating a catalog of operators and then go down the list of steps.