Testing Operator Deployment with OLM

Currently only the package manifests format is supported by <run|cleanup> subcommands. Bundle support is coming soon.

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 for commands to work with an OLM installation and generate a package manifests format.

• kubeconfig-path: the local path to a kubeconfig.
  • This uses well-defined default loading rules to load the config if empty.
• namespace: the cluster namespace in which Operator resources are created.
• manifests-dir: a directory containing the Operator’s package manifests.
• 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. packagemanifests/0.0.1 in an Operator SDK project.
• install-mode: specifies which supported installMode should be used to create an OperatorGroup by configuring its spec.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 a Namespace manifest to IncludePaths.
• timeout: a time string dictating the maximum time that run can run. The command will return an error if the timeout is exceeded.

• <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.