Testing Operator Deployment with OLM
This document discusses the behavior of operator-sdk <run|cleanup>
subcommands related to OLM deployment, and assumes you are familiar with OLM, related terminology, and have read the SDK-OLM integration design proposal.
Only the package manifests format is supported by <run|cleanup>
subcommands.
Note: before continuing, please read the caveats section below.
operator-sdk <run|cleanup> packagemanifests
command overview
operator-sdk <run|cleanup> packagemanifests
assumes OLM is already installed and running on your cluster, and that your Operator has a valid package manifests format. See the CLI overview for commands to work with an OLM installation and generate a package manifests format.
Let’s look at the anatomy of the run packagemanifests
(which is the same for cleanup
) configuration model:
- kubeconfig-path: the local path to a kubeconfig.
- This uses well-defined default loading rules to load the config if empty.
- olm-namespace: the namespace in which OLM is installed.
- operator-namespace: the cluster namespace in which Operator resources are created.
- This namespace must already exist in the cluster or be defined in a manifest passed to include-paths.
- manifests-dir: a directory containing the Operator’s package manifests.
- operator-version: the version of the Operator to deploy. It must be a semantic version, ex. 0.0.1.
- This version must match the version of the CSV manifest found in manifests-dir, ex.
deploy/olm-catalog/<operator-name>/0.0.1
in an Operator SDK project.
- This version must match the version of the CSV manifest found in manifests-dir, ex.
- install-mode: specifies which supported
installMode
should be used to create anOperatorGroup
by configuring itsspec.targetNamespaces
field.- The
InstallModeType
string passed must be marked as “supported” in the CSV being installed. The namespaces passed must exist or be created by passing aNamespace
manifest to IncludePaths. - This option understands the following strings (assuming your CSV does as well):
OwnNamespace
: the Operator will watch its own namespace (from operator-namespace or the kubeconfig default). This is the default.SingleNamespace="my-ns"
: the Operator will watch a namespace, not necessarily its own.AllNamespaces=""
: the Operator will watch all namespaces (cluster-scoped Operators).
- The
- include-paths: a list of paths to manifests of Kubernetes resources that either supplement or supplant defaults generated by
run
, ex. RBAC kinds.- This option can be used if you have an existing set of manifests outside your versioned package (ex. catalog manifests like a
Subscription
,CatalogSource
, and/orOperatorGroup
) you wish to use instead of the corresponding defaults.- Paths supplied to this command will be created with the same behavior of
kubectl create -f <path>
.
- Paths supplied to this command will be created with the same behavior of
- Kinds that are overridden if supplied:
CatalogSource
,Subscription
,OperatorGroup
.- If a
Subscription
orCatalogSource
are supplied, the other must be supplied since they are linked by field references.
- If a
- This option can be used if you have an existing set of manifests outside your versioned package (ex. catalog manifests like a
- timeout: a time string dictating the maximum time that
run
can run. The command will return an error if the timeout is exceeded.
Caveats
<run|cleanup> packagemanifests
are intended to be used for testing purposes only, since this command creates a transient image registry that should not be used in production. Typically a registry is deployed separately and a set of catalog manifests are created in the cluster to inform OLM of that registry and which Operator versions it can deploy and where to deploy the Operator.run packagemanifests
can only deploy one Operator and one version of that Operator at a time, hence its intended purpose being testing only.
Last modified July 8, 2020: docs: OLM integration docs reference new commands (new and legacy CLI) (#3320) (ec03835e)