operator-sdk generate packagemanifests

operator-sdk generate packagemanifests

Generates package manifests data for the operator

Synopsis

Note: while the package manifests format is not yet deprecated, the operator-framework is migrated towards using bundles by default. Run ‘operator-sdk generate bundle -h’ for more information.

This command generates a set of manifests in a versioned directory and a package manifest file for your operator. Each versioned directory consists of a ClusterServiceVersion (CSV), CustomResourceDefinitions (CRDs), and manifests not part of the CSV but required by the operator.

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 packagemanifests’ idempotently regenerates a packagemanifests directory, 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-packaged 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 packagemanifests’ 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 new package.

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

  1. operator-sdk generate packagemanifests [flags]

Examples

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

Options

  1. --channel string Channel name for the generated package
  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 Use the channel passed to --channel as the package manifest file's default channel
  4. --deploy-dir string Directory to read cluster-ready operator manifests from. If --crds-dir is not set, CRDs are ready from this directory
  5. --from-version string Semantic version of the operator being upgraded from
  6. -h, --help help for packagemanifests
  7. --input-dir string Directory to read existing package manifests from. This directory is the parent of individual versioned package directories, and different from --deploy-dir (default "packagemanifests")
  8. --kustomize-dir string Directory containing kustomize bases in a "bases" dir and a kustomization.yaml for operator-framework manifests (default "config/manifests")
  9. --output-dir string Directory in which to write package manifests
  10. --package string Package name
  11. -q, --quiet Run in quiet mode
  12. --stdout Write package to stdout
  13. --update-objects Update non-CSV objects in this package, ex. CustomResoureDefinitions, Roles (default true)
  14. -v, --version string Semantic version of the packaged operator

Options inherited from parent commands

  1. --plugins strings plugin keys of the plugin to initialize the project with
  2. --project-version string project version
  3. --verbose Enable verbose logging

SEE ALSO

Last modified February 25, 2021: generate: improve out-of-project usage, resolve ambiguous bundle flags (#4514) (bf88f3c9)