1. Documentation
×

Managing custom catalogs

This guide describes how to work with custom catalogs for Operators packaged using the bundle format on Operator Lifecycle Manager (OLM) in OKD.

Support for the legacy package manifest format for Operators, including custom catalogs that were using the legacy format, is removed in OKD 4.8 and later.

Kubernetes periodically deprecates certain APIs that are removed in subsequent releases. As a result, Operators are unable to use removed APIs starting with the version of OKD that uses the Kubernetes version that removed the API.

If your cluster is using custom catalogs, see Controlling Operator compatibility with OKD versions for more details about how Operator authors can update their projects to help avoid workload issues and prevent incompatible upgrades.
Additional resources

Prerequisites

Creating an index image

You can create an index image using the opm CLI.

Prerequisites

  • opm version 1.12.3+

  • podman version 1.9.3+

  • A bundle image built and pushed to a registry that supports Docker v2-2

    The internal registry of the OKD cluster cannot be used as the target registry because it does not support pushing without a tag, which is required during the mirroring process.
Procedure

  1. Start a new index:

    $ opm index add \
    --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \(1)
    --tag <registry>/<namespace>/<index_image_name>:<tag> \(2)
    [--binary-image <registry_base_image>] (3)
    1 Comma-separated list of bundle images to add to the index.
    2 The image tag that you want the index image to have.
    3 Optional: An alternative registry base image to use for serving the catalog.

  2. Push the index image to a registry.

    1. If required, authenticate with your target registry:

      $ podman login <registry>

    2. Push the index image:

      $ podman push <registry>/<namespace>/<index_image_name>:<tag>

Creating a catalog from an index image

You can create an Operator catalog from an index image and apply it to an OKD cluster for use with Operator Lifecycle Manager (OLM).

Prerequisites

  • An index image built and pushed to a registry.

Procedure

  1. Create a CatalogSource object that references your index image.

    1. Modify the following to your specifications and save it as a catalogSource.yaml file:

      apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: olm (1)
spec:
  sourceType: grpc
  image: <registry>:<port>/<namespace>/catalog:latest (2)
  displayName: My Operator Catalog
  publisher: <publisher_name> (3)
  updateStrategy:
    registryPoll: (4)
      interval: 30m
      1 If you want the catalog source to be available globally to users in all namespaces, specify the olm namespace. Otherwise, you can specify a different namespace for the catalog to be scoped and available only for that namespace.
      2 Specify your index image.
      3 Specify your name or an organization name publishing the catalog.
      4 Catalog sources can automatically check for new versions to keep up to date.

    2. Use the file to create the CatalogSource object:

      $ oc apply -f catalogSource.yaml

  2. Verify the following resources are created successfully.

    1. Check the pods:

      $ oc get pods -n olm
      Example output
      NAME                                    READY   STATUS    RESTARTS  AGE
my-operator-catalog-6njx6               1/1     Running   0         28s
marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. Check the catalog source:

      $ oc get catalogsource -n olm
      Example output
      NAME                  DISPLAY               TYPE PUBLISHER  AGE
my-operator-catalog   My Operator Catalog   grpc            5s

    3. Check the package manifest:

      $ oc get packagemanifest -n olm
      Example output
      NAME                          CATALOG               AGE
jaeger-product                My Operator Catalog   93s

You can now install the Operators from the OperatorHub page on your OKD web console.

Additional resources

Updating an index image

After configuring OperatorHub to use a catalog source that references a custom index image, cluster administrators can keep the available Operators on their cluster up to date by adding bundle images to the index image.

You can update an existing index image using the opm index add command.

Prerequisites

  • opm version 1.12.3+

  • podman version 1.9.3+

  • An index image built and pushed to a registry.

  • An existing catalog source referencing the index image.

Procedure

  1. Update the existing index by adding bundle images:

    $ opm index add \
    --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \(1)
    --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \(2)
    --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \(3)
    --pull-tool podman (4)
    1 The --bundles flag specifies a comma-separated list of additional bundle images to add to the index.
    2 The --from-index flag specifies the previously pushed index.
    3 The --tag flag specifies the image tag to apply to the updated index image.
    4 The --pull-tool flag specifies the tool used to pull container images.

    where:

    <registry>

    Specifies the hostname of the registry, such as quay.io or mirror.example.com.

    <namespace>

    Specifies the namespace of the registry, such as ocs-dev or abc.

    <new_bundle_image>

    Specifies the new bundle image to add to the registry, such as ocs-operator.

    <digest>

    Specifies the SHA image ID, or digest, of the bundle image, such as c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41.

    <existing_index_image>

    Specifies the previously pushed image, such as abc-redhat-operator-index.

    <existing_tag>

    Specifies a previously pushed image tag, such as 4.8.

    <updated_tag>

    Specifies the image tag to apply to the updated index image, such as 4.8.1.

    Example command
    $ opm index add \
    --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
    --from-index mirror.example.com/abc/abc-redhat-operator-index:4.8 \
    --tag mirror.example.com/abc/abc-redhat-operator-index:4.8.1 \
    --pull-tool podman

  2. Push the updated index image:

    $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>

  3. After Operator Lifecycle Manager (OLM) automatically polls the index image referenced in the catalog source at its regular interval, verify that the new packages are successfully added:

    $ oc get packagemanifests -n openshift-marketplace

Pruning an index image

An index image, based on the Operator bundle format, is a containerized snapshot of an Operator catalog. You can prune an index of all but a specified list of packages, which creates a copy of the source index containing only the Operators that you want.

Prerequisites

  • podman version 1.9.3+

  • grpcurl (third-party command-line tool)

  • opm version 1.18.0+

  • Access to a registry that supports Docker v2-2

    The internal registry of the OKD cluster cannot be used as the target registry because it does not support pushing without a tag, which is required during the mirroring process.
Procedure

  1. Authenticate with your target registry:

    $ podman login <target_registry>

  2. Determine the list of packages you want to include in your pruned index.

    1. Run the source index image that you want to prune in a container. For example:

      $ podman run -p50051:50051 \
    -it quay.io/operatorhubio/catalog:latest
      Example output
      Trying to pull quay.io/operatorhubio/catalog:latest...
Getting image source signatures
Copying blob ae8a0c23f5b1 done
...
INFO[0000] serving registry                              database=/database/index.db port=50051

    2. In a separate terminal session, use the grpcurl command to get a list of the packages provided by the index:

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out

    3. Inspect the packages.out file and identify which package names from this list you want to keep in your pruned index. For example:

      Example snippets of packages list
      ...
{
  "name": "couchdb-operator"
}
...
{
  "name": "eclipse-che"
}
...
{
{
  "name": "etcd"
}
...

    4. In the terminal session where you executed the podman run command, press Ctrl and C to stop the container process.

  3. Run the following command to prune the source index of all but the specified packages:

    $ opm index prune \
    -f quay.io/operatorhubio/catalog:latest \(1)
    -p couchdb-operator,eclipse-che,etcd \(2)
    [-i quay.io/openshift/origin-operator-registry:4.8.0] \(3)
    -t <target_registry>:<port>/<namespace>/catalog:latest (4)
    1 Index to prune.
    2 Comma-separated list of packages to keep.
    3 Required only for IBM Power Systems and IBM Z images: Operator Registry base image with the tag that matches the target OKD cluster major and minor version.
    4 Custom tag for new index image being built.

  4. Run the following command to push the new index image to your target registry:

    $ podman push <target_registry>:<port>/<namespace>/catalog:latest

    where <namespace> is any existing namespace on the registry.

Accessing images for Operators from private registries

If certain images relevant to Operators managed by Operator Lifecycle Manager (OLM) are hosted in an authenticated container image registry, also known as a private registry, OLM and OperatorHub are unable to pull the images by default. To enable access, you can create a pull secret that contains the authentication credentials for the registry. By referencing one or more pull secrets in a catalog source, OLM can handle placing the secrets in the Operator and catalog namespace to allow installation.

Other images required by an Operator or its Operands might require access to private registries as well. OLM does not handle placing the secrets in target tenant namespaces for this scenario, but authentication credentials can be added to the global cluster pull secret or individual namespace service accounts to enable the required access.

The following types of images should be considered when determining whether Operators managed by OLM have appropriate pull access:

Index images

A CatalogSource object can reference an index image, which use the Operator bundle format and are catalog sources packaged as container images hosted in images registries. If an index image is hosted in a private registry, a secret can be used to enable pull access.

Bundle images

Operator bundle images are metadata and manifests packaged as container images that represent a unique version of an Operator. If any bundle images referenced in a catalog source are hosted in one or more private registries, a secret can be used to enable pull access.

Operator and Operand images

If an Operator installed from a catalog source uses a private image, either for the Operator image itself or one of the Operand images it watches, the Operator will fail to install because the deployment will not have access to the required registry authentication. Referencing secrets in a catalog source does not enable OLM to place the secrets in target tenant namespaces in which Operands are installed.

Instead, the authentication details can be added to the global cluster pull secret in the openshift-config namespace, which provides access to all namespaces on the cluster. Alternatively, if providing access to the entire cluster is not permissible, the pull secret can be added to the default service accounts of the target tenant namespaces.

Prerequisites

  • At least one of the following hosted in a private registry:

    • An index image or catalog image.

    • An Operator bundle image.

    • An Operator or Operand image.

Procedure

  1. Create a secret for each required private registry.

    1. Log in to the private registry to create or update your registry credentials file:

      $ podman login <registry>:<port>

      The file path of your registry credentials can be different depending on the container tool used to log in to the registry. For the podman CLI, the default location is ${XDG_RUNTIME_DIR}/containers/auth.json. For the docker CLI, the default location is /root/.docker/config.json.

    2. It is recommended to include credentials for only one registry per secret, and manage credentials for multiple registries in separate secrets. Multiple secrets can be included in a CatalogSource object in later steps, and OKD will merge the secrets into a single virtual credentials file for use during an image pull.

      A registry credentials file can, by default, store details for more than one registry. Verify the current contents of your file. For example:

      File storing credentials for two registries
      {
        "auths": {
                "registry.redhat.io": {
                        "auth": "FrNHNydQXdzclNqdg=="
                },
                "quay.io": {
                        "auth": "Xd2lhdsbnRib21iMQ=="
                }
        }
}

      Because this file is used to create secrets in later steps, ensure that you are storing details for only one registry per file. This can be accomplished by using either of the following methods:

      • Use the podman logout <registry> command to remove credentials for additional registries until only the one registry you want remains.

      • Edit your registry credentials file and separate the registry details to be stored in multiple files. For example:

        File storing credentials for one registry
        {
        "auths": {
                "registry.redhat.io": {
                        "auth": "FrNHNydQXdzclNqdg=="
                }
        }
}
        File storing credentials for another registry
        {
        "auths": {
                "quay.io": {
                        "auth": "Xd2lhdsbnRib21iMQ=="
                }
        }
}

    3. Create a secret in the openshift-marketplace namespace that contains the authentication credentials for a private registry:

      $ oc create secret generic <secret_name> \
    -n openshift-marketplace \
    --from-file=.dockerconfigjson=<path/to/registry/credentials> \
    --type=kubernetes.io/dockerconfigjson

      Repeat this step to create additional secrets for any other required private registries, updating the --from-file flag to specify another registry credentials file path.

  2. Create or update an existing CatalogSource object to reference one or more secrets:

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  secrets: (1)
  - "<secret_name_1>"
  - "<secret_name_2>"
  image: <registry>:<port>/<namespace>/<image>:<tag>
  displayName: My Operator Catalog
  publisher: <publisher_name>
  updateStrategy:
    registryPoll:
      interval: 30m
    1 Add a spec.secrets section and specify any required secrets.

  3. If any Operator or Operand images that are referenced by a subscribed Operator require access to a private registry, you can either provide access to all namespaces in the cluster, or individual target tenant namespaces.

    • To provide access to all namespaces in the cluster, add authentication details to the global cluster pull secret in the openshift-config namespace.

      Cluster resources must adjust to the new global pull secret, which can temporarily limit the usability of the cluster.

      1. Extract the .dockerconfigjson file from the global pull secret:

        $ oc extract secret/pull-secret -n openshift-config --confirm

      2. Update the .dockerconfigjson file with your authentication credentials for the required private registry or registries and save it as a new file:

        $ cat .dockerconfigjson | \
    jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \(1)
    > new_dockerconfigjson
        1 Replace <registry>:<port>/<namespace> with the private registry details and <token> with your authentication credentials.

      3. Update the global pull secret with the new file:

        $ oc set data secret/pull-secret -n openshift-config \
    --from-file=.dockerconfigjson=new_dockerconfigjson

    • To update an individual namespace, add a pull secret to the service account for the Operator that requires access in the target tenant namespace.

      1. Recreate the secret that you created for the openshift-marketplace in the tenant namespace:

        $ oc create secret generic <secret_name> \
    -n <tenant_namespace> \
    --from-file=.dockerconfigjson=<path/to/registry/credentials> \
    --type=kubernetes.io/dockerconfigjson

      2. Verify the name of the service account for the Operator by searching the tenant namespace:

        $ oc get sa -n <tenant_namespace> (1)
        1 If the Operator was installed in an individual namespace, search that namespace. If the Operator was installed for all namespaces, search the openshift-operators namespace.
        Example output
        NAME            SECRETS   AGE
builder         2         6m1s
default         2         6m1s
deployer        2         6m1s
etcd-operator   2         5m18s (1)
        1 Service account for an installed etcd Operator.

      3. Link the secret to the service account for the Operator:

        $ oc secrets link <operator_sa> \
    -n <tenant_namespace> \
     <secret_name> \
    --for=pull
Additional resources

Disabling the default OperatorHub sources

Operator catalogs that source content provided by Red Hat and community projects are configured for OperatorHub by default during an OKD installation. As a cluster administrator, you can disable the set of default catalogs.

Procedure

  • Disable the sources for the default catalogs by adding disableAllDefaultSources: true to the OperatorHub object:

    $ oc patch OperatorHub cluster --type json \
    -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

Alternatively, you can use the web console to manage catalog sources. From the Administration → Cluster Settings → Global Configuration → OperatorHub page, click the Sources tab, where you can create, delete, disable, and enable individual sources.

Removing custom catalogs

As a cluster administrator, you can remove custom Operator catalogs that have been previously added to your cluster by deleting the related catalog source.

Procedure

  1. In the Administrator perspective of the web console, navigate to Administration → Cluster Settings.

  2. Click the Global Configuration tab, and then click OperatorHub.

  3. Click the Sources tab.

  4. Select the Options menu kebab for the catalog that you want to remove, and then click Delete CatalogSource.