operator-sdk generate bundle

operator-sdk generate bundle

Generates bundle data for the operator

Synopsis

Running ‘generate bundle’ is the first step to publishing your operator to a catalog and deploying it with OLM. This command both generates and packages files into an on-disk representation of an operator called a bundle. A bundle consists of a ClusterServiceVersion (CSV), CustomResourceDefinitions (CRDs), manifests not part of the CSV but required by the operator, some metadata (annotations.yaml), and a bundle.Dockerfile to build a bundle image.

A CSV manifest is generated by collecting data from the set of manifests passed to this command (see below), such as CRDs, RBAC, etc., and applying that data to a “base” CSV manifest. This base CSV can contain metadata, added by hand or by the ‘generate kustomize manifests’ command, and can be passed in like any other manifest (see below) or by file at the exact path ‘<kustomize-dir>/bases/<package-name>.clusterserviceversion.yaml’. Be aware that ‘generate bundle’ idempotently regenerates a bundle, so all non-metadata values in a base will be overwritten. If no base was passed in, input manifest data will be applied to an empty CSV.

There are two ways to pass the to-be-bundled set of manifests to this command: stdin via a Unix pipe, or in a directory using ‘–input-dir’. See command help for more information on these modes. Passing a directory is useful for running ‘generate bundle’ outside of a project or within a project that does not use kustomize and/or contains cluster-ready manifests on disk.

Set ‘–version’ to supply a semantic version for your bundle if you are creating one for the first time or upgrading an existing one.

If ‘–output-dir’ is set and you wish to build bundle images from that directory, either manually update your bundle.Dockerfile or set ‘–overwrite’.

More information on bundles: https://github.com/operator-framework/operator-registry/#manifest-format

  1. operator-sdk generate bundle [flags]

Examples

  1. # If running within a project or in a project that uses kustomize to generate manifests,
  2. # make sure a kustomize directory exists that looks like the following 'config/manifests' directory:
  3. $ tree config/manifests
  4. config/manifests
  5. ├── bases
  6. └── memcached-operator.clusterserviceversion.yaml
  7. └── kustomization.yaml
  8. # Generate a 0.0.1 bundle by passing manifests to stdin:
  9. $ kustomize build config/manifests | operator-sdk generate bundle --version 0.0.1
  10. Generating bundle version 0.0.1
  11. ...
  12. # If running outside of a project or in a project that does not use kustomize to generate manifests,
  13. # make sure cluster-ready manifests are available on disk:
  14. $ tree deploy/
  15. deploy/
  16. ├── crds
  17. └── cache.my.domain_memcacheds.yaml
  18. ├── deployment.yaml
  19. ├── role.yaml
  20. ├── role_binding.yaml
  21. ├── service_account.yaml
  22. └── webhooks.yaml
  23. # Generate a 0.0.1 bundle by passing manifests by dir:
  24. $ operator-sdk generate bundle --input-dir deploy --version 0.0.1
  25. Generating bundle version 0.0.1
  26. ...
  27. # After running in either of the above modes, you should see this directory structure:
  28. $ tree bundle/
  29. bundle/
  30. ├── manifests
  31. ├── cache.my.domain_memcacheds.yaml
  32. └── memcached-operator.clusterserviceversion.yaml
  33. └── metadata
  34. └── annotations.yaml

Options

  1. --channels string A comma-separated list of channels the bundle belongs to (default "alpha")
  2. --crds-dir string Directory to read cluster-ready CustomResoureDefinition manifests from. This option can only be used if --deploy-dir is set
  3. --default-channel string The default channel for the bundle
  4. --deploy-dir string Directory to read cluster-ready operator manifests from. If --crds-dir is not set, CRDs are ready from this directory. This option is mutually exclusive with --input-dir and piping to stdin
  5. --extra-service-accounts strings Names of service accounts, outside of the operator's Deployment account, that have bindings to {Cluster}Roles that should be added to the CSV
  6. -h, --help help for bundle
  7. --input-dir string Directory to read cluster-ready operator manifests from. This option is mutually exclusive with --deploy-dir/--crds-dir and piping to stdin. This option should not be passed an existing bundle directory, as this bundle will not contain the correct set of manifests required to generate a CSV. Use --kustomize-dir to pass a base CSV
  8. --kustomize-dir string Directory containing kustomize bases in a "bases" dir and a kustomization.yaml for operator-framework manifests (default "config/manifests")
  9. --manifests Generate bundle manifests
  10. --metadata Generate bundle metadata and Dockerfile
  11. --output-dir string Directory to write the bundle to
  12. --overwrite Overwrite the bundle's metadata and Dockerfile if they exist (default true)
  13. --package string Bundle's package name
  14. -q, --quiet Run in quiet mode
  15. --stdout Write bundle manifest to stdout
  16. -v, --version string Semantic version of the operator in the generated bundle. Only set if creating a new bundle or upgrading your operator

Options inherited from parent commands

  1. --plugins strings plugin keys to be used for this subcommand execution
  2. --verbose Enable verbose logging

SEE ALSO

Last modified May 26, 2021: generate bundle: add —extra-service-accounts flag to consider extra-Deployment SAs (#4826) (cc0422de)