Viewing Operator status

Understanding the state of the system in Operator Lifecycle Manager (OLM) is important for making decisions about and debugging problems with installed Operators. OLM provides insight into subscriptions and related catalog sources regarding their state and actions performed. This helps users better understand the healthiness of their Operators.

Operator subscription condition types

Subscriptions can report the following condition types:

Table 1. Subscription condition types
ConditionDescription

CatalogSourcesUnhealthy

Some or all of the catalog sources to be used in resolution are unhealthy.

InstallPlanMissing

An install plan for a subscription is missing.

InstallPlanPending

An install plan for a subscription is pending installation.

InstallPlanFailed

An install plan for a subscription has failed.

ResolutionFailed

The dependency resolution for a subscription has failed.

Default OKD cluster Operators are managed by the Cluster Version Operator (CVO) and they do not have a Subscription object. Application Operators are managed by Operator Lifecycle Manager (OLM) and they have a Subscription object.

Additional resources

Viewing Operator subscription status by using the CLI

You can view Operator subscription status by using the CLI.

Prerequisites

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

  • You have installed the OpenShift CLI (oc).

Procedure

  1. List Operator subscriptions:

    1. $ oc get subs -n <operator_namespace>

  2. Use the oc describe command to inspect a Subscription resource:

    1. $ oc describe sub <subscription_name> -n <operator_namespace>

  3. In the command output, find the Conditions section for the status of Operator subscription condition types. In the following example, the CatalogSourcesUnhealthy condition type has a status of false because all available catalog sources are healthy:

    Example output

    1. Name:         cluster-logging
    2. Namespace:    openshift-logging
    3. Labels:       operators.coreos.com/cluster-logging.openshift-logging=
    4. Annotations:  <none>
    5. API Version:  operators.coreos.com/v1alpha1
    6. Kind:         Subscription
    7. # ...
    8. Conditions:
    9.    Last Transition Time:  2019-07-29T13:42:57Z
    10.    Message:               all available catalogsources are healthy
    11.    Reason:                AllCatalogSourcesHealthy
    12.    Status:                False
    13.    Type:                  CatalogSourcesUnhealthy
    14. # ...

Default OKD cluster Operators are managed by the Cluster Version Operator (CVO) and they do not have a Subscription object. Application Operators are managed by Operator Lifecycle Manager (OLM) and they have a Subscription object.

Viewing Operator catalog source status by using the CLI

You can view the status of an Operator catalog source by using the CLI.

Prerequisites

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

  • You have installed the OpenShift CLI (oc).

Procedure

  1. List the catalog sources in a namespace. For example, you can check the olm namespace, which is used for cluster-wide catalog sources:

    1. $ oc get catalogsources -n olm

    Example output

    1. NAME                  DISPLAY               TYPE   PUBLISHER   AGE
    2. certified-operators   Certified Operators   grpc   Red Hat     55m
    3. community-operators   Community Operators   grpc   Red Hat     55m
    4. example-catalog       Example Catalog       grpc   Example Org 2m25s
    5. redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
    6. redhat-operators      Red Hat Operators     grpc   Red Hat     55m

  2. Use the oc describe command to get more details and status about a catalog source:

    1. $ oc describe catalogsource example-catalog -n olm

    Example output

    1. Name:         example-catalog
    2. Namespace:    olm
    3. Labels:       <none>
    4. Annotations:  operatorframework.io/managed-by: marketplace-operator
    5.               target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
    6. API Version:  operators.coreos.com/v1alpha1
    7. Kind:         CatalogSource
    8. # ...
    9. Status:
    10.   Connection State:
    11.     Address:              example-catalog.olm.svc:50051
    12.     Last Connect:         2021-09-09T17:07:35Z
    13.     Last Observed State:  TRANSIENT_FAILURE
    14.   Registry Service:
    15.     Created At:         2021-09-09T17:05:45Z
    16.     Port:               50051
    17.     Protocol:           grpc
    18.     Service Name:       example-catalog
    19.     Service Namespace:  olm
    20. # ...

    In the preceding example output, the last observed state is TRANSIENT_FAILURE. This state indicates that there is a problem establishing a connection for the catalog source.

  3. List the pods in the namespace where your catalog source was created:

    1. $ oc get pods -n olm

    Example output

    1. NAME                                    READY   STATUS             RESTARTS   AGE
    2. certified-operators-cv9nn               1/1     Running            0          36m
    3. community-operators-6v8lp               1/1     Running            0          36m
    4. marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
    5. example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
    6. redhat-marketplace-57p8c                1/1     Running            0          36m
    7. redhat-operators-smxx8                  1/1     Running            0          36m

    When a catalog source is created in a namespace, a pod for the catalog source is created in that namespace. In the preceding example output, the status for the example-catalog-bwt8z pod is ImagePullBackOff. This status indicates that there is an issue pulling the catalog source’s index image.

  4. Use the oc describe command to inspect a pod for more detailed information:

    1. $ oc describe pod example-catalog-bwt8z -n olm

    Example output

    1. Name:         example-catalog-bwt8z
    2. Namespace:    olm
    3. Priority:     0
    4. Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
    5. ...
    6. Events:
    7.   Type     Reason          Age                From               Message
    8.   ----     ------          ----               ----               -------
    9.   Normal   Scheduled       48s                default-scheduler  Successfully assigned olm/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
    10.   Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
    11.   Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
    12.   Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
    13.   Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
    14.   Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
    15.   Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

    In the preceding example output, the error messages indicate that the catalog source’s index image is failing to pull successfully because of an authorization issue. For example, the index image might be stored in a registry that requires login credentials.

Additional resources