This is a cache of https://docs.okd.io/latest/extensions/ce/managing-ce.html. It is a snapshot of the page at 2024-11-26T18:49:36.422+0000.
Managing extensions - Cluster extensions | Extensions | OKD 4
  1. Documentation
×

Managing cluster extensions

Operator Lifecycle Manager (OLM) v1 is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

After a catalog has been added to your cluster, you have access to the versions, patches, and over-the-air updates of the extensions and Operators that are published to the catalog.

You can manage extensions declaratively from the CLI using custom resources (CRs).

Currently, Operator Lifecycle Manager (OLM) v1 cannot authenticate private registries, such as the Red Hat-provided Operator catalogs. This is a known issue. As a result, the OLM v1 procedures that rely on having the Red Hat Operators catalog installed do not work. (OCPBUGS-36364)

Supported extensions

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.

Operator Lifecycle Manager (OLM) v1 does not support the OperatorConditions API introduced in existing OLM.

If an extension relies on only the OperatorConditions API to manage updates, the extension might not install correctly. Most extensions that rely on this API fail at start time, but some might fail during reconciliation.

As a workaround, you can pin your extension to a specific version. When you want to update your extension, consult the extension’s documentation to find out when it is safe to pin the extension to a new version.
Additional resources

Finding Operators to install from a catalog

After you add a catalog to your cluster, you can query the catalog to find Operators and extensions to install. Before you can query catalogs, you must port forward the catalog server service.

Prerequisites

  • You have added a catalog to your cluster.

  • You have installed the jq CLI tool.

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

    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 command 
      $ jq -s '.[] | select(.schema == "olm.package") | .name' \
  /home/username/catalogs/rhoc.json
      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 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 command 
    $ jq -s '.[] | select( .schema == "olm.package") | \
  select( .name == "openshift-pipelines-operator-rh")' \
  /home/username/rhoc.json
    Example output 
    {
  "defaultChannel": "stable",
  "icon": {
    "base64data": "PHN2ZyB4bWxu..."
    "mediatype": "image/png"
  },
  "name": "openshift-pipelines-operator-rh",
  "schema": "olm.package"
}

Common catalog queries

You can query catalogs by using the jq CLI tool.

Table 1. Common package queries
Query Request

Available packages in a catalog

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

Packages that support AllNamespaces install mode and do not use webhooks

 
$ 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}' \
  <catalog_name>.json

Package metadata

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

Catalog blobs in a package

 
$ jq -s '.[] | select( .package == "<package_name>")' \
  <catalog_name>.json
Table 2. Common channel queries
Query Request

Channels in a package

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

Versions in a channel

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

  • Latest version in a channel

  • upgrade path

 
$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select ( .name == "<channel>") | \
  select( .package == "<package_name>")' \
  <catalog_name>.json
Table 3. Common bundle queries
Query Request

Bundles in a package

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

  • Bundle dependencies

  • Available APIs

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

Creating a service account to manage cluster extensions

Unlike existing Operator Lifecycle Manager (OLM), OLM v1 does not have permissions to install, update, and manage cluster extensions. Cluster administrators must create a service account and assign the role-based access controls (RBAC) required to install, update, and manage cluster extensions.

There is a known issue in OLM v1. If you do not assign the correct role-based access controls (RBAC) to an extension’s service account, OLM v1 gets stuck and reconciliation stops.

Currently, OLM v1 does not have tools to help extension administrators find the correct RBAC for a service account.

Because OLM v1 is a Technology Preview feature and must not be used on production clusters, you can avoid this issue by using the more permissive RBAC included in the documentation.

This RBAC is intended for testing purposes only. Do not use it on production clusters.
Prerequisites

  • Access to an OKD cluster using an account with cluster-admin permissions.

Procedure

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

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: <extension>-installer
  namespace: <namespace>
    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:

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

Installing a cluster extension from a catalog

You can install an extension from a catalog by creating a custom resource (CR) and applying it to the cluster. Operator Lifecycle Manager (OLM) v1 supports installing cluster extensions, including existing OLM Operators via the registry+v1 bundle format, that are scoped to the cluster. For more information, see Supported extensions.

Currently, Operator Lifecycle Manager (OLM) v1 cannot authenticate private registries, such as the Red Hat-provided Operator catalogs. This is a known issue. As a result, the OLM v1 procedures that rely on having the Red Hat Operators catalog installed do not work. (OCPBUGS-36364)
Prerequisites

  • You have added a catalog to your cluster.

  • You have downloaded a local copy of the catalog file.

  • You have installed the jq CLI tool.

  • You have created a service account and assigned enough role-based access controls (RBAC) to install, update, and manage the extension you want to install. For more information, see Creating a service account.

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

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

Additional resources

Updating a cluster extension

You can update your cluster extension or Operator by manually editing the custom resource (CR) and applying the changes.

Prerequisites

  • You have a catalog installed.

  • You have downloaded a local copy of the catalog file.

  • You have an Operator or extension installed.

  • You have installed the jq CLI tool.

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

    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
Verification

  • Verify that the channel and version updates have been applied by running the following command:

    $ oc get clusterextension pipelines-operator -o yaml
    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.13"}}
  creationTimestamp: "2024-06-11T18:23:26Z"
  generation: 2
  name: pipelines-operator
  resourceVersion: "66310"
  uid: ce0416ba-13ea-4069-a6c8-e5efcbc47537
spec:
  channel: latest
  installNamespace: openshift-operators
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: <1.13
status:
  conditions:
  - lastTransitionTime: "2024-06-11T18:23:33Z"
    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:814742c8a7cc7e2662598e114c35c13993a7b423cfe92548124e43ea5d469f82"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2024-06-11T18:23:52Z"
    message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:814742c8a7cc7e2662598e114c35c13993a7b423cfe92548124e43ea5d469f82"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Installed
  - lastTransitionTime: "2024-06-11T18:23:33Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: Deprecated
  - lastTransitionTime: "2024-06-11T18:23:33Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: PackageDeprecated
  - lastTransitionTime: "2024-06-11T18:23:33Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: ChannelDeprecated
  - lastTransitionTime: "2024-06-11T18:23:33Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: BundleDeprecated
  installedBundle:
    name: openshift-pipelines-operator-rh.v1.12.2
    version: 1.12.2
  resolvedBundle:
    name: openshift-pipelines-operator-rh.v1.12.2
    version: 1.12.2
Troubleshooting

  • If you specify a target version or channel that is deprecated or does not exist, you can run the following command to check the status of your extension:

    $ oc get clusterextension <operator_name> -o yaml
    Example output for a version that does not exist 
    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":"3.0"}}
  creationTimestamp: "2024-06-11T18:23:26Z"
  generation: 3
  name: pipelines-operator
  resourceVersion: "71852"
  uid: ce0416ba-13ea-4069-a6c8-e5efcbc47537
spec:
  channel: latest
  installNamespace: openshift-operators
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: "3.0"
status:
  conditions:
  - lastTransitionTime: "2024-06-11T18:29:02Z"
    message: 'error upgrading from currently installed version "1.12.2": no package
      "openshift-pipelines-operator-rh" matching version "3.0" found in channel "latest"'
    observedGeneration: 3
    reason: ResolutionFailed
    status: "False"
    type: Resolved
  - lastTransitionTime: "2024-06-11T18:29:02Z"
    message: installation has not been attempted as resolution failed
    observedGeneration: 3
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  - lastTransitionTime: "2024-06-11T18:29:02Z"
    message: deprecation checks have not been attempted as resolution failed
    observedGeneration: 3
    reason: Deprecated
    status: Unknown
    type: Deprecated
  - lastTransitionTime: "2024-06-11T18:29:02Z"
    message: deprecation checks have not been attempted as resolution failed
    observedGeneration: 3
    reason: Deprecated
    status: Unknown
    type: PackageDeprecated
  - lastTransitionTime: "2024-06-11T18:29:02Z"
    message: deprecation checks have not been attempted as resolution failed
    observedGeneration: 3
    reason: Deprecated
    status: Unknown
    type: ChannelDeprecated
  - lastTransitionTime: "2024-06-11T18:29:02Z"
    message: deprecation checks have not been attempted as resolution failed
    observedGeneration: 3
    reason: Deprecated
    status: Unknown
    type: BundleDeprecated
Additional resources

Deleting an Operator

You can delete an Operator and its custom resource definitions (CRDs) by deleting the ClusterExtension custom resource (CR).

Prerequisites

  • You have a catalog installed.

  • You have an Operator installed.

Procedure

  • Delete an Operator and its CRDs by running the following command:

    $ oc delete clusterextension <operator_name>
    Example output
    clusterextension.olm.operatorframework.io "<operator_name>" deleted
Verification

  • Run the following commands to verify that your Operator and its resources were deleted:

    • Verify the Operator is deleted by running the following command:

      $ oc get clusterextensions
      Example output
      No resources found

    • Verify that the Operator’s system namespace is deleted by running the following command:

      $ oc get ns <operator_name>-system
      Example output
      Error from server (NotFound): namespaces "<operator_name>-system" not found