Managing custom catalogs - Administrator tasks | Operators

Prerequisites
File-based catalogs
- Creating a file-based catalog image
- Updating or filtering a file-based catalog image
SQLite-based catalogs
Catalog sources and pod security admission
Adding a catalog source to a cluster
Removing custom catalogs

Administrators with the dedicated-admin role and Operator catalog maintainers can create and manage custom catalogs packaged using the bundle format on Operator Lifecycle Manager (OLM) in OpenShift Dedicated.

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 OpenShift Dedicated that uses the Kubernetes version that removed the API.

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

Additional resources

Red Hat-provided Operator catalogs

Prerequisites

You have installed the opm cli.

File-based catalogs

File-based catalogs are the latest iteration of the catalog format in Operator Lifecycle Manager (OLM). It is a plain text-based (JSON or YAML) and declarative config evolution of the earlier SQLite database format, and it is fully backwards compatible.

As of OpenShift Dedicated 4.11, the default Red Hat-provided Operator catalog releases in the file-based catalog format. The default Red Hat-provided Operator catalogs for OpenShift Dedicated 4.6 through 4.10 released in the deprecated SQLite database format.

The opm subcommands, flags, and functionality related to the SQLite database format are also deprecated and will be removed in a future release. The features are still supported and must be used for catalogs that use the deprecated SQLite database format.

Many of the opm subcommands and flags for working with the SQLite database format, such as opm index prune, do not work with the file-based catalog format. For more information about working with file-based catalogs, see Operator Framework packaging format.

Creating a file-based catalog image

You can use the opm cli to create a catalog image that uses the plain text file-based catalog format (JSON or YAML), which replaces the deprecated SQLite database format.

Prerequisites

You have installed the opm cli.
You have podman version 1.9.3+.
A bundle image is built and pushed to a registry that supports Docker v2-2.

Procedure

Initialize the catalog:

Create a directory for the catalog by running the following command:
```
$ mkdir <catalog_dir>
```
Generate a Dockerfile that can build a catalog image by running the opm generate dockerfile command:
$ opm generate dockerfile <catalog_dir> \ -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v (1)
1 Specify the official Red Hat base image by using the -i flag, otherwise the Dockerfile uses the default upstream image.
The Dockerfile must be in the same parent directory as the catalog directory that you created in the previous step:
Example directory structure
. (1) ├── <catalog_dir> (2) └── <catalog_dir>.Dockerfile (3)
1 Parent directory

2 Catalog directory

3 Dockerfile generated by the opm generate dockerfile command

Populate the catalog with the package definition for your Operator by running the opm init command:

$ opm init <operator_name> \ (1)
    --default-channel=preview \ (2)
    --description=./README.md \ (3)
    --icon=./operator-icon.svg \ (4)
    --output yaml \ (5)
    > <catalog_dir>/index.yaml (6)

1	Operator, or package, name
2	Channel that subscriptions default to if unspecified
3	Path to the Operator’s `README.md` or other documentation
4	Path to the Operator’s icon
5	Output format: JSON or YAML
6	Path for creating the catalog configuration file

This command generates an olm.package declarative config blob in the specified catalog configuration file.

Add a bundle to the catalog by running the opm render command:
```
$ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ (1)
    --output=yaml \
    >> <catalog_dir>/index.yaml (2)
```
1 Pull spec for the bundle image

2 Path to the catalog configuration file

Channels must contain at least one bundle.
Add a channel entry for the bundle. For example, modify the following example to your specifications, and add it to your <catalog_dir>/index.yaml file:
Example channel entry
```
---
schema: olm.channel
package: <operator_name>
name: preview
entries:
  - name: <operator_name>.v0.1.0 (1)
```
1 Ensure that you include the period (.) after <operator_name> but before the v in the version. Otherwise, the entry fails to pass the opm validate command.
Validate the file-based catalog:
1. Run the opm validate command against the catalog directory:
  $ opm validate <catalog_dir>
2. Check that the error code is 0:
  $ echo $?
  Example output
  0

Build the catalog image by running the podman build command:

$ podman build . \
    -f <catalog_dir>.Dockerfile \
    -t <registry>/<namespace>/<catalog_image_name>:<tag>

Push the catalog image to a registry:
1. If required, authenticate with your target registry by running the podman login command:
  $ podman login <registry>
2. Push the catalog image by running the podman push command:
  $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>

Additional resources

opm cli reference

Updating or filtering a file-based catalog image

You can use the opm cli to update or filter a catalog image that uses the file-based catalog format. By extracting the contents of an existing catalog image, you can modify the catalog as needed, for example:

Adding packages
Removing packages
Updating existing package entries
Detailing deprecation messages per package, channel, and bundle

You can then rebuild the image as an updated version of the catalog.

Prerequisites

You have the following on your workstation:
- The opm cli.
- podman version 1.9.3+.
- A file-based catalog image.
- A catalog directory structure recently initialized on your workstation related to this catalog.
  
  If you do not have an initialized catalog directory, create the directory and generate the Dockerfile. For more information, see the "Initialize the catalog" step from the "Creating a file-based catalog image" procedure.

Procedure

Extract the contents of the catalog image in YAML format to an index.yaml file in your catalog directory:
```
$ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \
    -o yaml > <catalog_dir>/index.yaml
```
Alternatively, you can use the -o json flag to output in JSON format.

Modify the contents of the resulting index.yaml file to your specifications:

After a bundle has been published in a catalog, assume that one of your users has installed it. Ensure that all previously published bundles in a catalog have an update path to the current or newer channel head to avoid stranding users that have that version installed.

To add an Operator, follow the steps for creating package, bundle, and channel entries in the "Creating a file-based catalog image" procedure.

To remove an Operator, delete the set of olm.package, olm.channel, and olm.bundle blobs that relate to the package. The following example shows a set that must be deleted to remove the example-operator package from the catalog:

Example removed entries

---
defaultChannel: release-2.7
icon:
  base64data: <base64_string>
  mediatype: image/svg+xml
name: example-operator
schema: olm.package
---
entries:
- name: example-operator.v2.7.0
  skipRange: '>=2.6.0 <2.7.0'
- name: example-operator.v2.7.1
  replaces: example-operator.v2.7.0
  skipRange: '>=2.6.0 <2.7.1'
- name: example-operator.v2.7.2
  replaces: example-operator.v2.7.1
  skipRange: '>=2.6.0 <2.7.2'
- name: example-operator.v2.7.3
  replaces: example-operator.v2.7.2
  skipRange: '>=2.6.0 <2.7.3'
- name: example-operator.v2.7.4
  replaces: example-operator.v2.7.3
  skipRange: '>=2.6.0 <2.7.4'
name: release-2.7
package: example-operator
schema: olm.channel
---
image: example.com/example-inc/example-operator-bundle@sha256:<digest>
name: example-operator.v2.7.0
package: example-operator
properties:
- type: olm.gvk
  value:
    group: example-group.example.io
    kind: MyObject
    version: v1alpha1
- type: olm.gvk
  value:
    group: example-group.example.io
    kind: MyOtherObject
    version: v1beta1
- type: olm.package
  value:
    packageName: example-operator
    version: 2.7.0
- type: olm.bundle.object
  value:
    data: <base64_string>
- type: olm.bundle.object
  value:
    data: <base64_string>
relatedImages:
- image: example.com/example-inc/example-related-image@sha256:<digest>
  name: example-related-image
schema: olm.bundle
---

To add or update deprecation messages for an Operator, ensure there is a deprecations.yaml file in the same directory as the package’s index.yaml file. For information on the deprecations.yaml file format, see "olm.deprecations schema".

Save your changes.
Validate the catalog:
```
$ opm validate <catalog_dir>
```

Rebuild the catalog:

$ podman build . \
    -f <catalog_dir>.Dockerfile \
    -t <registry>/<namespace>/<catalog_image_name>:<tag>

Push the updated catalog image to a registry:

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

Verification

In the web console, navigate to the OperatorHub configuration resource in the Administration → Cluster Settings → Configuration page.
Add the catalog source or update the existing catalog source to use the pull spec for your updated catalog image.

For more information, see "Adding a catalog source to a cluster" in the "Additional resources" of this section.
After the catalog source is in a READY state, navigate to the Operators → OperatorHub page and check that the changes you made are reflected in the list of Operators.

SQLite-based catalogs

The SQLite database format for Operator catalogs is a deprecated feature. Deprecated functionality is still included in OpenShift Dedicated and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments.

For the most recent list of major functionality that has been deprecated or removed within OpenShift Dedicated, refer to the Deprecated and removed features section of the OpenShift Dedicated release notes.

Creating a SQLite-based index image

You can create an index image based on the SQLite database format by using the opm cli.

Prerequisites

You have installed the opm cli.
You have podman version 1.9.3+.
A bundle image is built and pushed to a registry that supports Docker v2-2.

Procedure

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.

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>

Updating a SQLite-based index image

After configuring OperatorHub to use a catalog source that references a custom index image, administrators with the dedicated-admin role 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

You have installed the opm cli.
You have podman version 1.9.3+.
An index image is built and pushed to a registry.
You have an existing catalog source referencing the index image.

Procedure

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 .
<updated_tag>: Specifies the image tag to apply to the updated index image, such as .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: \
    --tag mirror.example.com/abc/abc-redhat-operator-index:.1 \
    --pull-tool podman

Push the updated index image:

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

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
```

Filtering a SQLite-based index image

An index image, based on the Operator bundle format, is a containerized snapshot of an Operator catalog. You can filter, or 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

You have podman version 1.9.3+.
You have grpcurl (third-party command-line tool).
You have installed the opm cli.
You have access to a registry that supports Docker v2-2.

Procedure

Authenticate with your target registry:
```
$ podman login <target_registry>
```
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 registry.redhat.io/redhat/redhat-operator-index:v
  Example output
  Trying to pull registry.redhat.io/redhat/redhat-operator-index:v... 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": "advanced-cluster-management" } ... { "name": "jaeger-product" } ... { { "name": "quay-operator" } ...
4. In the terminal session where you executed the podman run command, press Ctrl and C to stop the container process.

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

$ opm index prune \
    -f registry.redhat.io/redhat/redhat-operator-index:v \(1)
    -p advanced-cluster-management,jaeger-product,quay-operator \(2)
    [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \(3)
    -t <target_registry>:<port>/<namespace>/redhat-operator-index:v (4)

1	Index to prune.
2	Comma-separated list of packages to keep.
3	Required only for IBM Power® and IBM Z® images: Operator Registry base image with the tag that matches the target OpenShift Dedicated cluster major and minor version.
4	Custom tag for new index image being built.

Run the following command to push the new index image to your target registry:
```
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v
```
where <namespace> is any existing namespace on the registry.

Catalog sources and pod security admission

Pod security admission was introduced in OpenShift Dedicated 4.11 to ensure pod security standards. Catalog sources built using the SQLite-based catalog format and a version of the opm cli tool released before OpenShift Dedicated 4.11 cannot run under restricted pod security enforcement.

In OpenShift Dedicated , namespaces do not have restricted pod security enforcement by default and the default catalog source security mode is set to legacy.

Default restricted enforcement for all namespaces is planned for inclusion in a future OpenShift Dedicated release. When restricted enforcement occurs, the security context of the pod specification for catalog source pods must match the restricted pod security standard. If your catalog source image requires a different pod security standard, the pod security admissions label for the namespace must be explicitly set.

If you do not want to run your SQLite-based catalog source pods as restricted, you do not need to update your catalog source in OpenShift Dedicated .

However, it is recommended that you take action now to ensure your catalog sources run under restricted pod security enforcement. If you do not take action to ensure your catalog sources run under restricted pod security enforcement, your catalog sources might not run in future OpenShift Dedicated releases.

As a catalog author, you can enable compatibility with restricted pod security enforcement by completing either of the following actions:

Migrate your catalog to the file-based catalog format.
Update your catalog image with a version of the opm cli tool released with OpenShift Dedicated 4.11 or later.

The SQLite database catalog format is deprecated, but still supported by Red Hat. In a future release, the SQLite database format will not be supported, and catalogs will need to migrate to the file-based catalog format. As of OpenShift Dedicated 4.11, the default Red Hat-provided Operator catalog is released in the file-based catalog format. File-based catalogs are compatible with restricted pod security enforcement.

If you do not want to update your SQLite database catalog image or migrate your catalog to the file-based catalog format, you can configure your catalog to run with elevated permissions.

Additional resources

Understanding and managing pod security admission

Migrating SQLite database catalogs to the file-based catalog format

You can update your deprecated SQLite database format catalogs to the file-based catalog format.

Prerequisites

You have a SQLite database catalog source.
You have access to the cluster as a user with the dedicated-admin role.
You have the latest version of the opm cli tool released with OpenShift Dedicated on your workstation.

Procedure

Migrate your SQLite database catalog to a file-based catalog by running the following command:
```
$ opm migrate <registry_image> <fbc_directory>
```

Generate a Dockerfile for your file-based catalog by running the following command:

$ opm generate dockerfile <fbc_directory> \
  --binary-image \
  registry.redhat.io/openshift4/ose-operator-registry:v

Next steps

The generated Dockerfile can be built, tagged, and pushed to your registry.

Additional resources

Adding a catalog source to a cluster

Rebuilding SQLite database catalog images

You can rebuild your SQLite database catalog image with the latest version of the opm cli tool that is released with your version of OpenShift Dedicated.

Prerequisites

You have a SQLite database catalog source.
You have access to the cluster as a user with the dedicated-admin role.
You have the latest version of the opm cli tool released with OpenShift Dedicated on your workstation.

Procedure

Run the following command to rebuild your catalog with a more recent version of the opm cli tool:

$ opm index add --binary-image \
  registry.redhat.io/openshift4/ose-operator-registry:v \
  --from-index <your_registry_image> \
  --bundles "" -t \<your_registry_image>

Configuring catalogs to run with elevated permissions

If you do not want to update your SQLite database catalog image or migrate your catalog to the file-based catalog format, you can perform the following actions to ensure your catalog source runs when the default pod security enforcement changes to restricted:

Manually set the catalog security mode to legacy in your catalog source definition. This action ensures your catalog runs with legacy permissions even if the default catalog security mode changes to restricted.
Label the catalog source namespace for baseline or privileged pod security enforcement.

The SQLite database catalog format is deprecated, but still supported by Red Hat. In a future release, the SQLite database format will not be supported, and catalogs will need to migrate to the file-based catalog format. File-based catalogs are compatible with restricted pod security enforcement.

Prerequisites

You have a SQLite database catalog source.
You have access to the cluster as a user with the dedicated-admin role.
You have a target namespace that supports running pods with the elevated pod security admission standard of baseline or privileged.

Procedure

Edit the CatalogSource definition by setting the spec.grpcPodConfig.securityContextConfig label to legacy, as shown in the following example:

Example CatalogSource definition

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-catsrc
  namespace: my-ns
spec:
  sourceType: grpc
  grpcPodConfig:
    securityContextConfig: legacy
  image: my-image:latest

In OpenShift Dedicated , the spec.grpcPodConfig.securityContextConfig field is set to legacy by default. In a future release of OpenShift Dedicated, it is planned that the default setting will change to restricted. If your catalog cannot run under restricted enforcement, it is recommended that you manually set this field to legacy.

Edit your <namespace>.yaml file to add elevated pod security admission standards to your catalog source namespace, as shown in the following example:

Example <namespace>.yaml file

apiVersion: v1
kind: Namespace
metadata:
...
  labels:
    security.openshift.io/scc.podSecurityLabelSync: "false" (1)
    openshift.io/cluster-monitoring: "true"
    pod-security.kubernetes.io/enforce: baseline (2)
  name: "<namespace_name>"

1	Turn off pod security label synchronization by adding the `security.openshift.io/scc.podSecurityLabelSync=false` label to the namespace.
2	Apply the pod security admission `pod-security.kubernetes.io/enforce` label. Set the label to `baseline` or `privileged`. Use the `baseline` pod security profile unless other workloads in the namespace require a `privileged` profile.

Adding a catalog source to a cluster

Adding a catalog source to an OpenShift Dedicated cluster enables the discovery and installation of Operators for users. Administrators with the dedicated-admin role can create a CatalogSource object that references an index image. OperatorHub uses catalog sources to populate the user interface.

Alternatively, you can use the web console to manage catalog sources. From the Home → Search page, select a project, click the Resources drop-down and search for CatalogSource. You can create, update, delete, disable, and enable individual sources.

Prerequisites

You built and pushed an index image to a registry.
You have access to the cluster as a user with the dedicated-admin role.

Procedure

Create a CatalogSource object that references your index image.

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: openshift-marketplace (1)
  annotations:
    olm.catalogImageTemplate: (2)
      "<registry>/<namespace>/<index_image_name>:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
spec:
  sourceType: grpc
  grpcPodConfig:
    securityContextConfig: <security_mode> (3)
  image: <registry>/<namespace>/<index_image_name>:<tag> (4)
  displayName: My Operator Catalog
  publisher: <publisher_name> (5)
  updateStrategy:
    registryPoll: (6)
      interval: 30m

1	If you want the catalog source to be available globally to users in all namespaces, specify the `openshift-marketplace` namespace. Otherwise, you can specify a different namespace for the catalog to be scoped and available only for that namespace.
2	Optional: Set the `olm.catalogImageTemplate` annotation to your index image name and use one or more of the Kubernetes cluster version variables as shown when constructing the template for the image tag.
3	Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future OpenShift Dedicated release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
4	Specify your index image. If you specify a tag after the image name, for example `:v`, the catalog source pod uses an image pull policy of `Always`, meaning the pod always pulls the image prior to starting the container. If you specify a digest, for example `@sha256:<id>`, the image pull policy is `IfNotPresent`, meaning the pod pulls the image only if it does not already exist on the node.
5	Specify your name or an organization name publishing the catalog.
6	Catalog sources can automatically check for new versions to keep up to date.

Use the file to create the CatalogSource object:
```
$ oc apply -f catalogSource.yaml
```

Verify the following resources are created successfully.

Check the pods:

$ oc get pods -n openshift-marketplace

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

Check the catalog source:

$ oc get catalogsource -n openshift-marketplace

Example output

NAME                  DISPLAY               TYPE PUBLISHER  AGE
my-operator-catalog   My Operator Catalog   grpc            5s

Check the package manifest:

$ oc get packagemanifest -n openshift-marketplace

Example output

NAME                          CATALOG               AGE
jaeger-product                My Operator Catalog   93s

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

Additional resources

Operator Lifecycle Manager concepts and resources → Catalog source

Removing custom catalogs

As an administrator with the dedicated-admin role, you can remove custom Operator catalogs that have been previously added to your cluster by deleting the related catalog source.

Prerequisites

You have access to the cluster as a user with the dedicated-admin role.

Procedure

In the Administrator perspective of the web console, navigate to Home → Search.
Select a project from the Project: list.
Select CatalogSource from the Resources list.
Select the Options menu for the catalog that you want to remove, and then click Delete CatalogSource.

1	Parent directory
2	Catalog directory
3	Dockerfile generated by the `opm generate dockerfile` command

1	Pull spec for the bundle image
2	Path to the catalog configuration file