OLM and Bundle CLI Overview

This document gives an overview of using operator-sdk to work with Operator manifests related to OLM, namely bundles and package manifests. See the manifests generation doc for an in-depth discussion of these commands.

OLM installation

The following operator-sdk subcommands manage an OLM installation:

• olm install: install a particular version of OLM.
• olm status: check the status of a particular version of OLM running in a cluster. This command can infer the version of an error-free OLM installation.
• olm uninstall: uninstall a particular version of OLM running in a cluster. This command can infer the version of an error-free OLM installation.

Manifests and metadata

The following make recipes and operator-sdk subcommands create or interact with Operator package manifests and bundles:

• generate kustomize manifests: creates kustomize bases and a kustomization.yaml in config/manifests.

Bundles

• make bundle: runs the following commands:
  • generate kustomize manifests: see above.
  • generate bundle: creates a new or updates an existing bundle in the <project-root>/bundle directory. This command generates both manifests and metadata.
  • bundle validate: validates an Operator bundle image or unpacked manifests and metadata.
• make bundle-build: builds a bundle image using the bundle.Dockerfile generated by make bundle.
• run bundle: runs the given Operator’s bundle image with an existing OLM installation.
• run bundle-upgrade: upgrades the Operator bundle to a specified newer version.

Private bundle and catalog image registries

By default, projects are configured to push to and pull from a docker.io registry with namespace being the value passed to operator-sdk init --domain=<value>. Modify this value to push/pull bundle and catalog images with a different registry host or namespace.

All bundle and catalog image-related commands invoke opm (except for bundle image builds, for which docker is used directly). opm leverages the host’s image build/pull tools indirectly to perform various image tasks, so if your image registry is private or has a custom CA you must ensure the in-use build tool is able to push to/pull from the registry:

• docker: config.json, certificate configuration
• podman: auth.json, certificate configuration
• none (containerd): uses docker’s config.json, certificate configuration

The run bundle or run bundle-upgrade commands use the none image tool, described above, in-cluster. These commands accept the names of secrets available in the deployment namesace that contain configuration file data. Ideally a cluster admin will provision a namespace and service account for bundle testing, such that they include and reference these secrets:

• Create an image pull secret for your config.json and add it to your service account.

• Create a generic secret with a cert.pem key containing root certificate(s) for your registry.

Once the above secrets have been created, run the either command with --pull-secret-name=<image pull secret> and --ca-secret-name=<certificate secret>:

operator-sdk run bundle private-custom-ca-reg.com/memcached-operator-bundle:v0.0.2 \
    --index-image private-custom-ca-reg.com/memcached-operator-catalog:v0.0.1 \
    --pull-secret-name foo-pull-sec \
    --ca-secret-name foo-cert-sec

You may have to set --namespace=<provisioned namespace> if the namespace encoded in your kubeconfig’s current context was not provisioned with these secrets.

Package Manifests

• generate packagemanifests: creates a new or updates an existing versioned directory as part of the package manifests in the <project-root>/packagemanifests directory.
• run packagemanifests: runs an Operator’s package manifests format with an existing OLM installation.