OLM Integration Package Manifests Quickstart

    This guide assumes you have followed the introduction and Setup section of the bundle quickstart, and have added the target to your Makefile as described .

    Important: this guide assumes your project was scaffolded with operator-sdk init --project-version=3. These features are unavailable to projects of version 2 or less; this information can be found by inspecting your PROJECT file’s version value.

    We will now create a package manifests format by running make packagemanifests in the root of the memcached-operator project:

    A versioned manifests directory packagemanifests/0.0.1 containing a CSV and all CRDs in config/crds and a package manifest YAML file packagemanifests/<project-name>.package.yaml have been created in the Operator project.

    At this point in development we’ve generated all files necessary to build a memcached-operator registry. Now we’re ready to test the Operator with OLM.

    run packagemanifests performs some optionally configurable setup under the hood, but for most use cases the following invocation is all we need:

    1. $ operator-sdk run packagemanifests --version 0.0.1
    2. INFO[0000] Running operator from directory packagemanifests
    3. INFO[0000] Creating memcached-operator registry         
    4. INFO[0000]   Creating ConfigMap "olm/memcached-operator-registry-manifests-package"
    5. INFO[0000]   Creating ConfigMap "olm/memcached-operator-registry-manifests-0-0-1"
    6. INFO[0000]   Creating Deployment "olm/memcached-operator-registry-server"
    7. INFO[0000]   Creating Service "olm/memcached-operator-registry-server"
    8. INFO[0000] Waiting for Deployment "olm/memcached-operator-registry-server" rollout to complete
    9. INFO[0000]   Waiting for Deployment "olm/memcached-operator-registry-server" to rollout: 0 of 1 updated replicas are available
    10. INFO[0066]   Deployment "olm/memcached-operator-registry-server" successfully rolled out
    11. INFO[0066] Creating resources                           
    12. INFO[0066]   Creating CatalogSource "default/memcached-operator-ocs"
    13. INFO[0066]   Creating Subscription "default/memcached-operator-v0-0-1-sub"
    14. INFO[0066]   Creating OperatorGroup "default/operator-sdk-og"
    15. INFO[0066] Waiting for ClusterServiceVersion "default/memcached-operator.v0.0.1" to reach 'Succeeded' phase
    16. INFO[0066]   Waiting for ClusterServiceVersion "default/memcached-operator.v0.0.1" to appear
    17. INFO[0073]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: Pending
    18. INFO[0077]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: InstallReady
    20. INFO[0037] Successfully installed "memcached-operator.v0.0.1" on OLM version "0.15.1"
    22. NAME                            NAMESPACE    KIND                        STATUS
    23. memcacheds.cache.example.com    default      CustomResourceDefinition    Installed
    24. memcached-operator.v0.0.1       default      ClusterServiceVersion       Installed

    As long as both the ClusterServiceVersion and all CustomResourceDefinition‘s return an Installed status, the memcached-operator has been deployed successfully.

    Now that we’re done testing the memcached-operator, we should probably clean up the Operator’s resources. will do this for you:

    1. $ operator-sdk cleanup memcached-operator
    2. INFO[0000] subscription "memcached-operator-v0-0-1-sub" deleted
    3. INFO[0000] customresourcedefinition "memcacheds.cache.example.com" deleted
    4. INFO[0000] clusterserviceversion "memcached-operator.v0.0.1" deleted
    5. INFO[0000] clusterrole "memcached-operator-metrics-reader" deleted
    6. INFO[0000] serviceaccount "default" deleted
    7. INFO[0000] role "memcached-operator.v0.0.1-jhjk7" deleted
    8. INFO[0000] rolebinding "memcached-operator.v0.0.1-jhjk7-default-mxv6m" deleted
    9. INFO[0000] catalogsource "memcached-operator-ocs" deleted
    10. INFO[0000] operatorgroup "operator-sdk-og" deleted
    11. INFO[0001] operator "memcached-operator" uninstalled

    In order to migrate packagemanifests to bundles, operator-sdk pkgman-to-bundle command can be used.

    As an example, consider the packagemanifests directory to have the following structure:

    1. $ operator-sdk pkgman-to-bundle packagemanifests --output-dir etcd-bundle/
    2. INFO[0000] Packagemanifests will be migrated to bundles in bundle directory
    3. INFO[0000] Creating etcd-bundle/bundle-0.0.1/bundle.Dockerfile
    4. INFO[0000] Creating etcd-bundle/bundle-0.0.1/metadata/annotations.yaml
    5. ...

    This will create output bundles in the directory etcd-bundle. The output directory will look like:

    1. ├── bundle-0.0.1
    2. │   ├── bundle
    4. │   │   │   ├── etcdcluster.crd.yaml
    5. │   │   │   ├── etcdoperator.clusterserviceversion.yaml
    6. │   │   ├── metadata
    7. │   │   │   └── annotations.yaml
    8. │   │   └── tests
    9. │   │       └── scorecard
    10. │   │           └── config.yaml
    11. │   └── bundle.Dockerfile
    12. └── bundle-0.0.2
    13.     ├── bundle
    14.     │   ├── manifests
    15.     │   │   ├── etcdbackup.crd.yaml
    16.     │   │   ├── etcdcluster.crd.yaml
    17.     │   │   ├── etcdoperator.v0.0.2.clusterserviceversion.yaml
    18.     │   │   ├── etcdrestore.crd.yaml
    19.     │   └── metadata
    20.     │       └── annotations.yaml
    21.     └── bundle.Dockerfile

    To build images for the bundles, the base container image name can be provided using --image-tag-base flag. This name should be provided without the tag (: and characters following), as the command will tag each bundle image with its packagemanifests directory name, i.e. <image-tag-base>:<dir-name>. For example, the following command for the above packagemnifests directory would build the bundles quay.io/example/etcd-bundle:0.0.1 and quay.io/example/etcd-bundle:0.0.2.

    A custom command can also be specified to build images, using the --build-cmd flag. The default command is docker build. For example:

    1. $ operator-sdk pkgman-to-bundle packagemanifests --output-dir etcd-bundle/ --image-tag-base quay.io/example/etcd --build-cmd "podman build -f bundle.Dockerfile . -t"

    However, if using a custom command, it needs to be made sure that the command is in the PATH or a fully qualified path name is provided as input to the flag.

    Once the command has finished building your bundle images and they have been added to a catalog image, delete all bundle directories except for the latest one. This directory will contain manifests for your operator’s head bundle, and should be versioned with version control system like git. Move this directory and its bundle.Dockerfile to your project’s root: