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