Extensions

1. Maintain a single configuration file for the catalog, containing image references for each Operator in the catalog:

   Example catalog configuration file

   name: community-operators
   repo: quay.io/community-operators/catalog
   tag: latest
   references:
   - name: etcd-operator
     image: quay.io/etcd-operator/index@sha256:5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03
   - name: prometheus-operator
     image: quay.io/prometheus-operator/index@sha256:e258d248fda94c63753607f7c4494ee0fcbe92f1a76bfdac795c9d84101eb317

2. Run a script that parses the configuration file and creates a new catalog from its references:

   Example script

   name=$(yq eval '.name' catalog.yaml)
   mkdir "$name"
   yq eval '.name + "/" + .references[].name' catalog.yaml | xargs mkdir
   for l in $(yq e '.name as $catalog | .references[] | .image + "|" + $catalog + "/" + .name + "/index.yaml"' catalog.yaml); do
     image=$(echo $l | cut -d'|' -f1)
     file=$(echo $l | cut -d'|' -f2)
     opm render "$image" > "$file"
   done
   opm generate dockerfile "$name"
   indexImage=$(yq eval '.repo + ":" + .tag' catalog.yaml)
   docker build -t "$indexImage" -f "$name.Dockerfile" .
   docker push "$indexImage"

Procedure

1. Create a catalog custom resource (CR), similar to the following example:

   Example redhat-operators.yaml

   apiVersion: catalogd.operatorframework.io/v1alpha1
   kind: ClusterCatalog
   metadata:
     name: redhat-operators
   spec:
     source:
       type: image
       image:
         ref: registry.redhat.io/redhat/redhat-operator-index:v4.17 1
         pullSecret: <pull_secret_name> 2
         pollInterval: <poll_interval_duration> 3

   1

   Specify the catalog’s image in the spec.source.image field.

   2

   If your catalog is hosted on a secure registry, such as registry.redhat.io, you must create a pull secret scoped to the openshift-catalog namespace.

   3

   Specify the interval for polling the remote registry for newer image digests. The default value is 24h. Valid units include seconds (s), minutes (m), and hours (h). To disable polling, set a zero value, such as 0s.

2. Add the catalog to your cluster by running the following command:

   $ oc apply -f redhat-operators.yaml

   Example output

   catalog.catalogd.operatorframework.io/redhat-operators created

Procedure

1. Initialize the catalog:

   1. Create a directory for the catalog by running the following command:

      $ mkdir <catalog_dir>

   2. 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:v4.17 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

   3. 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.

2. 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

   Note

   Channels must contain at least one bundle.

3. 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.

4. 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

5. Build the catalog image by running the podman build command:

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

6. 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>

Procedure

1. 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

   Note

   Alternatively, you can use the -o json flag to output in JSON format.

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

   Important

   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 4.12. 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".
3. Save your changes.

4. Validate the catalog:

   $ opm validate <catalog_dir>

5. Rebuild the catalog:

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

6. Push the updated catalog image to a registry:

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

Verification

1. In the web console, navigate to the OperatorHub configuration resource in the Administration → Cluster Settings → Configuration page.

2. 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.

3. 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.

Procedure

1. Port forward the catalog server service in the openshift-catalogd namespace by running the following command:

   $ oc -n openshift-catalogd port-forward svc/catalogd-catalogserver 8080:443

2. In a new terminal window or tab, download the catalog’s JSON file locally by running the following command:

   $ curl -L -k https://localhost:8080/catalogs/<catalog_name>/all.json \
     -C - -o /<path>/<catalog_name>.json

   Example 5.1. Example command

   $ curl -L -k https://localhost:8080/catalogs/redhat-operators/all.json \
     -C - -o /home/username/catalogs/rhoc.json

3. Run one of the following commands to return a list of Operators and extensions in a catalog.

   Important

   Currently, Operator Lifecycle Manager (OLM) v1 supports installing cluster extensions that meet all of the following criteria:

   • The extension must use the registry+v1 bundle format introduced in existing OLM.
   • The extension must support installation via the AllNamespaces install mode.
   • The extension must not use webhooks.

   • The extension must not declare dependencies by using any of the following file-based catalog properties:

     • olm.gvk.required
     • olm.package.required
     • olm.constraint

   OLM v1 checks that the extension you want to install meets these constraints. If the extension that you want to install does not meet these constraints, an error message is printed in the cluster extension’s conditions.

   • Get a list of all the Operators and extensions from the local catalog file by running the following command:

     $ jq -s '.[] | select(.schema == "olm.package") | .name' \
       /<path>/<filename>.json

     Example 5.2. Example command

     $ jq -s '.[] | select(.schema == "olm.package") | .name' \
       /home/username/catalogs/rhoc.json

     Example 5.3. Example output

     NAME                                                        AGE
     "3scale-operator"
     "advanced-cluster-management"
     "amq-broker-rhel8"
     "amq-online"
     "amq-streams"
     "amq7-interconnect-operator"
     "ansible-automation-platform-operator"
     "ansible-cloud-addons-operator"
     "apicast-operator"
     "aws-efs-csi-driver-operator"
     "aws-load-balancer-operator"
     "bamoe-businessautomation-operator"
     "bamoe-kogito-operator"
     "bare-metal-event-relay"
     "businessautomation-operator"
     ...

   • Get list of packages that support AllNamespaces install mode and do not use webhooks from the local catalog file by running the following command:

     $ jq -c 'select(.schema == "olm.bundle") | \
       {"package":.package, "version":.properties[] | \
       select(.type == "olm.bundle.object").value.data | @base64d | fromjson | \
       select(.kind == "ClusterServiceVersion" and (.spec.installModes[] | \
       select(.type == "AllNamespaces" and .supported == true) != null) \
       and .spec.webhookdefinitions == null).spec.version}' \
       /<path>/<catalog_name>.json

     Example 5.4. Example output

     {"package":"3scale-operator","version":"0.10.0-mas"}
     {"package":"3scale-operator","version":"0.10.5"}
     {"package":"3scale-operator","version":"0.11.0-mas"}
     {"package":"3scale-operator","version":"0.11.1-mas"}
     {"package":"3scale-operator","version":"0.11.2-mas"}
     {"package":"3scale-operator","version":"0.11.3-mas"}
     {"package":"3scale-operator","version":"0.11.5-mas"}
     {"package":"3scale-operator","version":"0.11.6-mas"}
     {"package":"3scale-operator","version":"0.11.7-mas"}
     {"package":"3scale-operator","version":"0.11.8-mas"}
     {"package":"amq-broker-rhel8","version":"7.10.0-opr-1"}
     {"package":"amq-broker-rhel8","version":"7.10.0-opr-2"}
     {"package":"amq-broker-rhel8","version":"7.10.0-opr-3"}
     {"package":"amq-broker-rhel8","version":"7.10.0-opr-4"}
     {"package":"amq-broker-rhel8","version":"7.10.1-opr-1"}
     {"package":"amq-broker-rhel8","version":"7.10.1-opr-2"}
     {"package":"amq-broker-rhel8","version":"7.10.2-opr-1"}
     {"package":"amq-broker-rhel8","version":"7.10.2-opr-2"}
     ...

4. Inspect the contents of an Operator or extension’s metadata by running the following command:

   $ jq -s '.[] | select( .schema == "olm.package") | \
     select( .name == "<package_name>")' /<path>/<catalog_name>.json

   Example 5.5. Example command

   $ jq -s '.[] | select( .schema == "olm.package") | \
     select( .name == "openshift-pipelines-operator-rh")' \
     /home/username/rhoc.json

   Example 5.6. Example output

   {
     "defaultChannel": "stable",
     "icon": {
       "base64data": "PHN2ZyB4bWxu..."
       "mediatype": "image/png"
     },
     "name": "openshift-pipelines-operator-rh",
     "schema": "olm.package"
   }

Procedure

1. Create a service account, similar to the following example:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: <extension>-installer
     namespace: <namespace>

   Example 5.7. Example extension-service-account.yaml file

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: pipelines-installer
     namespace: pipelines

2. Apply the service account by running the following command:

   $ oc apply -f extension-service-account.yaml

3. Create a cluster role and assign RBAC, similar to the following example:

   Warning

   The following cluster role does not follow the principle of least privilege. This cluster role is intended for testing purposes only. Do not use it on production clusters.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: <extension>-installer-clusterrole
   rules:
   - apiGroups: ["*"]
     resources: ["*"]
     verbs: ["*"]

   Example 5.8. Example pipelines-cluster-role.yaml file

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: pipelines-installer-clusterrole
   rules:
   - apiGroups: ["*"]
     resources: ["*"]
     verbs: ["*"]

4. Add the cluster role to the cluster by running the following command:

   $ oc apply -f pipelines-role.yaml

5. Bind the permissions granted by the cluster role to the service account by creating a cluster role binding, similar to the following example:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: <extension>-installer-binding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: <extension>-installer-clusterrole
   subjects:
   - kind: ServiceAccount
     name: <extension>-installer
     namespace: <namespace>

   Example 5.9. Example pipelines-cluster-role-binding.yaml file

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: pipelines-installer-binding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: pipelines-installer-clusterrole
   subjects:
   - kind: ServiceAccount
     name: pipelines-installer
     namespace: pipelines

6. Apply the cluster role binding by running the following command:

   $ oc apply -f pipelines-cluster-role-binding.yaml

Procedure

1. Inspect a package for channel and version information from a local copy of your catalog file by completing the following steps:

   1. Get a list of channels from a selected package by running the following command:

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
        select( .package == "<package_name>") | \
        .name' /<path>/<catalog_name>.json

      Example 5.10. Example command

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
        select( .package == "openshift-pipelines-operator-rh") | \
        .name' /home/username/rhoc.json

      Example 5.11. Example output

      "latest"
      "pipelines-1.11"
      "pipelines-1.12"
      "pipelines-1.13"
      "pipelines-1.14"

   2. Get a list of the versions published in a channel by running the following command:

      $ jq -s '.[] | select( .package == "<package_name>" ) | \
        select( .schema == "olm.channel" ) | \
        select( .name == "<channel_name>" ) | .entries | \
        .[] | .name' /<path>/<catalog_name>.json

      Example 5.12. Example command

      $ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
      select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
      .entries | .[] | .name' /home/username/rhoc.json

      Example 5.13. Example output

      "openshift-pipelines-operator-rh.v1.12.0"
      "openshift-pipelines-operator-rh.v1.12.1"
      "openshift-pipelines-operator-rh.v1.12.2"
      "openshift-pipelines-operator-rh.v1.13.0"
      "openshift-pipelines-operator-rh.v1.13.1"
      "openshift-pipelines-operator-rh.v1.11.1"
      "openshift-pipelines-operator-rh.v1.12.0"
      "openshift-pipelines-operator-rh.v1.12.1"
      "openshift-pipelines-operator-rh.v1.12.2"
      "openshift-pipelines-operator-rh.v1.13.0"
      "openshift-pipelines-operator-rh.v1.14.1"
      "openshift-pipelines-operator-rh.v1.14.2"
      "openshift-pipelines-operator-rh.v1.14.3"
      "openshift-pipelines-operator-rh.v1.14.4"

2. If you want to install your extension into a new namespace, run the following command:

   $ oc adm new-project <new_namespace>

3. Create a CR, similar to the following example:

   Example pipelines-operator.yaml CR

   apiVersion: olm.operatorframework.io/v1alpha1
   kind: ClusterExtension
   metadata:
     name: pipelines-operator
   spec:
     packageName: openshift-pipelines-operator-rh
     installNamespace: <namespace>
     serviceAccount:
       name: <service_account>
     channel: <channel>
     version: "<version>"

   where:

   <namespace>

   Specifies the namespace where you want the bundle installed, such as pipelines or my-extension. Extensions are still cluster-scoped and might contain resources that are installed in different namespaces.

   <service_account>

   Specifies the name of the service account you created to install, update, and manage your extension.

   <channel>

   Optional: Specifies the channel, such as pipelines-1.11 or latest, for the package you want to install or update.

   <version>

   Optional: Specifies the version or version range, such as 1.11.1, 1.12.x, or >=1.12.1, of the package you want to install or update. For more information, see "Example custom resources (CRs) that specify a target version" and "Support for version ranges".

   Important

   If you try to install an Operator or extension that does not have unique name, the installation might fail or lead to an unpredictable result. This occurs for the following reasons:

   • If mulitple catalogs are installed on a cluster, Operator Lifecycle Manager (OLM) v1 does not include a mechanism to specify a catalog when you install an Operator or extension.
   • OLM v1 requires that all of the Operators and extensions that are available to install on a cluster use a unique name for their bundles and packages.

4. Apply the CR to the cluster by running the following command:

   $ oc apply -f pipeline-operator.yaml

   Example output

   clusterextension.olm.operatorframework.io/pipelines-operator created

Verification

1. View the Operator or extension’s CR in the YAML format by running the following command:

   $ oc get clusterextension pipelines-operator -o yaml

   Example 5.14. Example output

   apiVersion: v1
   items:
   - apiVersion: olm.operatorframework.io/v1alpha1
     kind: ClusterExtension
     metadata:
       annotations:
         kubectl.kubernetes.io/last-applied-configuration: |
           {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"pipelines","packageName":"openshift-pipelines-operator-rh","serviceAccount":{"name":"pipelines-installer"},"pollInterval":"30m"}}
       creationTimestamp: "2024-06-10T17:50:51Z"
       finalizers:
       - olm.operatorframework.io/cleanup-unpack-cache
       generation: 1
       name: pipelines-operator
       resourceVersion: "53324"
       uid: c54237be-cde4-46d4-9b31-d0ec6acc19bf
     spec:
       channel: latest
       installNamespace: pipelines
       packageName: openshift-pipelines-operator-rh
       serviceAccount:
         name: pipelines-installer
       upgradeConstraintPolicy: Enforce
     status:
       conditions:
       - lastTransitionTime: "2024-06-10T17:50:58Z"
         message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"
         observedGeneration: 1
         reason: Success
         status: "True"
         type: Resolved
       - lastTransitionTime: "2024-06-10T17:51:11Z"
         message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"
         observedGeneration: 1
         reason: Success
         status: "True"
         type: Installed
       - lastTransitionTime: "2024-06-10T17:50:58Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: Deprecated
       - lastTransitionTime: "2024-06-10T17:50:58Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: PackageDeprecated
       - lastTransitionTime: "2024-06-10T17:50:58Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: ChannelDeprecated
       - lastTransitionTime: "2024-06-10T17:50:58Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: BundleDeprecated
       - lastTransitionTime: "2024-06-10T17:50:58Z"
         message: 'unpack successful:
         observedGeneration: 1
         reason: UnpackSuccess
         status: "True"
         type: Unpacked
       installedBundle:
         name: openshift-pipelines-operator-rh.v1.14.4
         version: 1.14.4
       resolvedBundle:
         name: openshift-pipelines-operator-rh.v1.14.4
         version: 1.14.4

   where:

   spec.channel

   Displays the channel defined in the CR of the extension.

   spec.version

   Displays the version or version range defined in the CR of the extension.

   status.conditions

   Displays information about the status and health of the extension.

   type: Deprecated

   Displays whether one or more of following are deprecated:

   type: PackageDeprecated

   Displays whether the resolved package is deprecated.

   type: ChannelDeprecated

   Displays whether the resolved channel is deprecated.

   type: BundleDeprecated

   Displays whether the resolved bundle is deprecated.

   The value of False in the status field indicates that the reason: Deprecated condition is not deprecated. The value of True in the status field indicates that the reason: Deprecated condition is deprecated.

   installedBundle.name

   Displays the name of the bundle installed.

   installedBundle.version

   Displays the version of the bundle installed.

   resolvedBundle.name

   Displays the name of the resolved bundle.

   resolvedBundle.version

   Displays the version of the resolved bundle.

Procedure

1. Inspect a package for channel and version information from a local copy of your catalog file by completing the following steps:

   1. Get a list of channels from a selected package by running the following command:

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
        select( .package == "<package_name>") | \
        .name' /<path>/<catalog_name>.json

      Example 5.15. Example command

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
        select( .package == "openshift-pipelines-operator-rh") | \
        .name' /home/username/rhoc.json

      Example 5.16. Example output

      "latest"
      "pipelines-1.11"
      "pipelines-1.12"
      "pipelines-1.13"
      "pipelines-1.14"

   2. Get a list of the versions published in a channel by running the following command:

      $ jq -s '.[] | select( .package == "<package_name>" ) | \
        select( .schema == "olm.channel" ) | \
        select( .name == "<channel_name>" ) | .entries | \
        .[] | .name' /<path>/<catalog_name>.json

      Example 5.17. Example command

      $ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
      select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
      .entries | .[] | .name' /home/username/rhoc.json

      Example 5.18. Example output

      "openshift-pipelines-operator-rh.v1.11.1"
      "openshift-pipelines-operator-rh.v1.12.0"
      "openshift-pipelines-operator-rh.v1.12.1"
      "openshift-pipelines-operator-rh.v1.12.2"
      "openshift-pipelines-operator-rh.v1.13.0"
      "openshift-pipelines-operator-rh.v1.14.1"
      "openshift-pipelines-operator-rh.v1.14.2"
      "openshift-pipelines-operator-rh.v1.14.3"
      "openshift-pipelines-operator-rh.v1.14.4"

2. Find out what version or channel is specified in your Operator or extension’s CR by running the following command:

   $ oc get clusterextension <operator_name> -o yaml

   Example command

   $ oc get clusterextension pipelines-operator -o yaml

   Example 5.19. Example output

   apiVersion: olm.operatorframework.io/v1alpha1
   kind: ClusterExtension
   metadata:
     annotations:
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"openshift-operators","packageName":"openshift-pipelines-operator-rh","pollInterval":"30m","version":"\u003c1.12"}}
     creationTimestamp: "2024-06-11T15:55:37Z"
     generation: 1
     name: pipelines-operator
     resourceVersion: "69776"
     uid: 6a11dff3-bfa3-42b8-9e5f-d8babbd6486f
   spec:
     channel: latest
     installNamespace: openshift-operators
     packageName: openshift-pipelines-operator-rh
     upgradeConstraintPolicy: Enforce
     version: <1.12
   status:
     conditions:
     - lastTransitionTime: "2024-06-11T15:56:09Z"
       message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
       observedGeneration: 1
       reason: Success
       status: "True"
       type: Installed
     - lastTransitionTime: "2024-06-11T15:55:50Z"
       message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
       observedGeneration: 1
       reason: Success
       status: "True"
       type: Resolved
     - lastTransitionTime: "2024-06-11T15:55:50Z"
       message: ""
       observedGeneration: 1
       reason: Deprecated
       status: "False"
       type: Deprecated
     - lastTransitionTime: "2024-06-11T15:55:50Z"
       message: ""
       observedGeneration: 1
       reason: Deprecated
       status: "False"
       type: PackageDeprecated
     - lastTransitionTime: "2024-06-11T15:55:50Z"
       message: ""
       observedGeneration: 1
       reason: Deprecated
       status: "False"
       type: ChannelDeprecated
     - lastTransitionTime: "2024-06-11T15:55:50Z"
       message: ""
       observedGeneration: 1
       reason: Deprecated
       status: "False"
       type: BundleDeprecated
     installedBundle:
       name: openshift-pipelines-operator-rh.v1.11.1
       version: 1.11.1
     resolvedBundle:
       name: openshift-pipelines-operator-rh.v1.11.1
       version: 1.11.1

3. Edit your CR by using one of the following methods:

   • If you want to pin your Operator or extension to specific version, such as 1.12.1, edit your CR similar to the following example:

     Example pipelines-operator.yaml CR

     apiVersion: olm.operatorframework.io/v1alpha1
     kind: ClusterExtension
     metadata:
       name: pipelines-operator
     spec:
       packageName: openshift-pipelines-operator-rh
       installNamespace: <namespace>
       version: "1.12.1" 1

     1

     Update the version from 1.11.1 to 1.12.1

   • If you want to define a range of acceptable update versions, edit your CR similar to the following example:

     Example CR with a version range specified

     apiVersion: olm.operatorframework.io/v1alpha1
     kind: ClusterExtension
     metadata:
       name: pipelines-operator
     spec:
       packageName: openshift-pipelines-operator-rh
       installNamespace: <namespace>
       version: ">1.11.1, <1.13" 1

     1

     Specifies that the desired version range is greater than version 1.11.1 and less than 1.13. For more information, see "Support for version ranges" and "Version comparison strings".

   • If you want to update to the latest version that can be resolved from a channel, edit your CR similar to the following example:

     Example CR with a specified channel

     apiVersion: olm.operatorframework.io/v1alpha1
     kind: ClusterExtension
     metadata:
       name: pipelines-operator
     spec:
       packageName: openshift-pipelines-operator-rh
       installNamespace: <namespace>
       channel: pipelines-1.13 1

     1

     Installs the latest release that can be resolved from the specified channel. Updates to the channel are automatically installed.

   • If you want to specify a channel and version or version range, edit your CR similar to the following example:

     Example CR with a specified channel and version range

     apiVersion: olm.operatorframework.io/v1alpha1
     kind: ClusterExtension
     metadata:
       name: pipelines-operator
     spec:
       packageName: openshift-pipelines-operator-rh
       installNamespace: <namespace>
       channel: latest
       version: "<1.13"

     For more information, see "Example custom resources (CRs) that specify a target version".

4. Apply the update to the cluster by running the following command:

   $ oc apply -f pipelines-operator.yaml

   Example output

   clusterextension.olm.operatorframework.io/pipelines-operator configured

   Tip

   You can patch and apply the changes to your CR from the CLI by running the following command:

   $ oc patch clusterextension/pipelines-operator -p \
     '{"spec":{"version":"<1.13"}}' \
     --type=merge

   Example output

   clusterextension.olm.operatorframework.io/pipelines-operator patched

Procedure

1. Edit the custom resource (CR) of your Operator or extension as shown in the following example:

   Example CR

   apiVersion: olm.operatorframework.io/v1alpha1
   kind: Operator
   metadata:
     name: <operator_name> 1
   spec:
     packageName: <package_name> 2
     installNamespace: <namespace_name>
     serviceAccount:
       name: <service_account>
     version: <version> 3
     upgradeConstraintPolicy: Ignore 4

   1

   Specifies the name of the Operator or extension, such as pipelines-operator

   2

   Specifies the package name, such as openshift-pipelines-operator-rh.

   3

   Specifies the blocked update or rollback version.

   4

   Optional: Specifies the upgrade constraint policy. To force an update or rollback, set the field to Ignore. If unspecified, the default setting is Enforce.

2. Apply the changes to your Operator or extensions CR by running the following command:

   $ oc apply -f <extension_name>.yaml

Procedure

1. Edit the ClusterExtension object of the CRD:

   $ oc edit clusterextension <clusterextension_name>

2. Set the preflight.crdUpgradeSafety.disabled field to true:

   Example 5.22. Example ClusterExtension object

   apiVersion: olm.operatorframework.io/v1alpha1
   kind: ClusterExtension
   metadata:
       name: clusterextension-sample
   spec:
       installNamespace: default
       packageName: argocd-operator
       version: 0.6.0
       preflight:
           crdUpgradeSafety:
               disabled: true 1

   1

   Set to true.