1. Documentation
×

Validating Operator bundles

As an Operator author, you can run the bundle validate command in the Operator SDK to validate the content and format of an Operator bundle. You can run the command on a remote Operator bundle image or a local Operator bundle directory.

The Red Hat-supported version of the Operator SDK CLI tool, including the related scaffolding and testing tools for Operator projects, is deprecated and is planned to be removed in a future release of OKD. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements and will be removed from future OKD releases.

The Red Hat-supported version of the Operator SDK is not recommended for creating new Operator projects. Operator authors with existing Operator projects can use the version of the Operator SDK CLI tool released with OKD 4.16 to maintain their projects and create Operator releases targeting newer versions of OKD.

The following related base images for Operator projects are not deprecated. The runtime functionality and configuration APIs for these base images are still supported for bug fixes and for addressing CVEs.

  • The base image for Ansible-based Operator projects

  • The base image for Helm-based Operator projects

For the most recent list of major functionality that has been deprecated or removed within OKD, refer to the Deprecated and removed features section of the OKD release notes.

For information about the unsupported, community-maintained, version of the Operator SDK, see Operator SDK (Operator Framework).

About the bundle validate command

While the Operator SDK scorecard command can run tests on your Operator based on a configuration file and test images, the bundle validate subcommand can validate local bundle directories and remote bundle images for content and structure.

bundle validate command syntax
$ operator-sdk bundle validate <bundle_dir_or_image> <flags>

The bundle validate command runs automatically when you build your bundle using the make bundle command.

Bundle images are pulled from a remote registry and built locally before they are validated. Local bundle directories must contain Operator metadata and manifests. The bundle metadata and manifests must have a structure similar to the following bundle layout:

Example bundle layout
./bundle
  ├── manifests
  │   ├── cache.my.domain_memcacheds.yaml
  │   └── memcached-operator.clusterserviceversion.yaml
  └── metadata
      └── annotations.yaml

Bundle tests pass validation and finish with an exit code of 0 if no errors are detected.

Example output
INFO[0000] All validation tests have completed successfully

Tests fail validation and finish with an exit code of 1 if errors are detected.

Example output
ERRO[0000] Error: Value cache.example.com/v1alpha1, Kind=Memcached: CRD "cache.example.com/v1alpha1, Kind=Memcached" is present in bundle "" but not defined in CSV

Bundle tests that result in warnings can still pass validation with an exit code of 0 as long as no errors are detected. Tests only fail on errors.

Example output
WARN[0000] Warning: Value : (memcached-operator.v0.0.1) annotations not found
INFO[0000] All validation tests have completed successfully

For further information about the bundle validate subcommand, run:

$ operator-sdk bundle validate -h

Built-in bundle validate tests

The Operator SDK ships with pre-defined validators arranged into suites. If you run the bundle validate command without specifying a validator, the default test runs. The default test verifies that a bundle adheres to the specifications defined by the Operator Framework community. For more information, see "Bundle format".

You can run optional validators to test for issues such as OperatorHub compatibility or deprecated Kubernetes APIs. Optional validators always run in addition to the default test.

bundle validate command syntax for optional test suites
$ operator-sdk bundle validate <bundle_dir_or_image>
  --select-optional <test_label>
Table 1. Addtional bundle validate validators
Name Description Label

Operator Framework

This validator tests an Operator bundle against the entire suite of validators provided by the Operator Framework.

suite=operatorframework

OperatorHub

This validator tests an Operator bundle for compatibility with OperatorHub.

name=operatorhub

Good Practices

This validator tests whether an Operator bundle complies with good practices as defined by the Operator Framework. It checks for issues, such as an empty CRD description or unsupported Operator Lifecycle Manager (OLM) resources.

name=good-practices
Additional resources

Running the bundle validate command

The default validator runs a test every time you enter the bundle validate command. You can run optional validators using the --select-optional flag. Optional validators run tests in addition to the default test.

Prerequisites

  • Operator project generated by using the Operator SDK

Procedure

  1. If you want to run the default validator against a local bundle directory, enter the following command from your Operator project directory:

    $ operator-sdk bundle validate ./bundle

  2. If you want to run the default validator against a remote Operator bundle image, enter the following command:

    $ operator-sdk bundle validate \
  <bundle_registry>/<bundle_image_name>:<tag>

    where:

    <bundle_registry>

    Specifies the registry where the bundle is hosted, such as quay.io/example.

    <bundle_image_name>

    Specifies the name of the bundle image, such as memcached-operator.

    <tag>

    Specifies the tag of the bundle image, such as v1.31.0.

    If you want to validate an Operator bundle image, you must host your image in a remote registry. The Operator SDK pulls the image and builds it locally before running tests. The bundle validate command does not support testing local bundle images.

  3. If you want to run an additional validator against an Operator bundle, enter the following command:

    $ operator-sdk bundle validate \
  <bundle_dir_or_image> \
  --select-optional <test_label>

    where:

    <bundle_dir_or_image>

    Specifies the local bundle directory or remote bundle image, such as ~/projects/memcached or quay.io/example/memcached-operator:v1.31.0.

    <test_label>

    Specifies the name of the validator you want to run, such as name=good-practices.

    Example output
    ERRO[0000] Error: Value apiextensions.k8s.io/v1, Kind=CustomResource: unsupported media type registry+v1 for bundle object
WARN[0000] Warning: Value k8sevent.v0.0.1: owned CRD "k8sevents.k8s.k8sevent.com" has an empty description

Validating your Operator’s multi-platform readiness

You can validate your Operator’s multi-platform readiness by running the bundle validate command. The command verifies that your Operator project meets the following conditions:

  • Your Operator’s manager image supports the platforms labeled in the cluster service version (CSV) file.

  • Your Operator’s CSV has labels for the supported platforms for Operator Lifecycle Manager (OLM) and OperatorHub.

Procedure

  • Run the following command to validate your Operator project for multiple architecture readiness:

    $ operator-sdk bundle validate ./bundle \
  --select-optional name=multiarch
    Example validation message
    INFO[0020] All validation tests have completed successfully
    Example error message for missing CSV labels in the manager image
    ERRO[0016] Error: Value test-operator.v0.0.1: not all images specified are providing the support described via the CSV labels. Note that (SO.architecture): (linux.ppc64le) was not found for the image(s) [quay.io/example-org/test-operator:v1alpha1]
ERRO[0016] Error: Value test-operator.v0.0.1: not all images specified are providing the support described via the CSV labels. Note that (SO.architecture): (linux.s390x) was not found for the image(s) [quay.io/example-org/test-operator:v1alpha1]
ERRO[0016] Error: Value test-operator.v0.0.1: not all images specified are providing the support described via the CSV labels. Note that (SO.architecture): (linux.amd64) was not found for the image(s) [quay.io/example-org/test-operator:v1alpha1]
ERRO[0016] Error: Value test-operator.v0.0.1: not all images specified are providing the support described via the CSV labels. Note that (SO.architecture): (linux.arm64) was not found for the image(s) [quay.io/example-org/test-operator:v1alpha1]
    Example error message for missing OperatorHub flags
    WARN[0014] Warning: Value test-operator.v0.0.1: check if the CSV is missing the label (operatorframework.io/arch.<value>) for the Arch(s): ["amd64" "arm64" "ppc64le" "s390x"]. Be aware that your Operator manager image ["quay.io/example-org/test-operator:v1alpha1"] provides this support. Thus, it is very likely that you want to provide it and if you support more than amd64 architectures, you MUST,use the required labels for all which are supported.Otherwise, your solution cannot be listed on the cluster for these architectures
Additional resources