Assembling the Metadata Bundle

The format of the metadata bundle is distinctly different from the convention used to submit community operators.

Depending on the format of your operator's metadata bundle, you may have to flatten any nested subdirectories, and possibly also remove any extraneous files from inclusion into the metadata archive. Skipping this step will result in your metadata failing the certification pipeline due to being invalid. The operator-courier tool is what's used by the certification pipeline to lint and validate metadata submissions.

Below is an example tree layout of a "broken" metadata bundle for an operator named example:

└── example
    ├── example.crd.yaml
    ├── example-operator.v0.1.0.clusterserviceversion.yaml
    ├── example-operator.v0.2.0.clusterserviceversion.yaml
    ├── example.package.yaml
    ├── some-extraneous-file.txt
    └── somedir
        └── some-other-file.yaml

You can see in the above that there are the usual operator metadata files (1 CRD, 2 CSVs and 1 package.yaml) with a couple of extra files and a directory thrown in. Before submitting an operator metadata bundle to Red Hat Connect, you need to archive only the relevant files that are part of the operator metadata (any CRDs, CSVs, and package.yaml files), omitting any extraneous files or directories. One caveat is that you can't just zip up the bundle directory itself and upload that, since the yaml files would be nested in a subdirectory within the archive.

Using the example bundle directory above, a valid metadata archive can be created using the linux zip utility as follows:

$ cd /path/to/bundle/example
$ zip example-metadata *.yaml

In the above command, we simply changed to the metadata bundle directory, as might originally be cloned from the community-operators GitHub repo. Then the zip command was run, with archive name as the first argument (sans .zip file extension) and a file glob matching only yaml files in the current directory. This works fine, as long as there aren't important metadata files nested in any sub directories inside the bundle directory being archived, which shouldn't be the case if using your metadata bundle as submitted previously to GitHub. A quick way to verify the contents is to use the unzip tool:

$ unzip -l example-metadata.zip
Archive:  example-metadata.zip
  inflating: example-operator-v0.1.0.clusterserviceversion.yaml  
  inflating: example-operator.v0.2.0.clusterserviceversion.yaml
  inflating: example.crd.yaml
  inflating: example.package.yaml

With your metadata bundle ready, you can now upload the metadata to Connect.