$ operator-sdk bundle validate <bundle_dir_or_image> <flags>
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.17 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.
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). |
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 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:
./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.
INFO[0000] All validation tests have completed successfully
Tests fail validation and finish with an exit code of 1
if errors are detected.
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.
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
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>
Name | Description | Label |
---|---|---|
Operator Framework |
This validator tests an Operator bundle against the entire suite of validators provided by the Operator Framework. |
|
OperatorHub |
This validator tests an Operator bundle for compatibility with 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. |
|
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.
Operator project generated by using the Operator SDK
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
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:
Specifies the registry where the bundle is hosted, such as quay.io/example
.
Specifies the name of the bundle image, such as memcached-operator
.
Specifies the tag of the bundle image, such as v1.36.1
.
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 |
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:
Specifies the local bundle directory or remote bundle image, such as ~/projects/memcached
or quay.io/example/memcached-operator:v1.36.1
.
Specifies the name of the validator you want to run, such as name=good-practices
.
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
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.
Run the following command to validate your Operator project for multiple architecture readiness:
$ operator-sdk bundle validate ./bundle \
--select-optional name=multiarch
INFO[0020] All validation tests have completed successfully
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]
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