Bug 1746044 - CatalogSource status should show error info
Summary: CatalogSource status should show error info
Keywords:
Status: CLOSED DUPLICATE of bug 1737081
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Evan Cordell
QA Contact: Jian Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-27 14:27 UTC by Abu Kashem
Modified: 2019-08-27 14:43 UTC (History)
0 users

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-27 14:43:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Abu Kashem 2019-08-27 14:27:32 UTC
CatalogSource status should show the following information
- If a `ConfigMap` is missing the status should reflect that.
- Any error while setting up the registry pod
- Last observed state of the gRPC connection to the registry pod.

Currently none of the information is available in the status block of a CatalogSource. 

How to reproduce:
a)
 1. Create a `CatalogSource` object that points to an non existing ConfigMap object.

Actual Results:
- The status block of the CatalogSource will have no information regarding the missing ConfigMap object.

Expected Results:
- The status block of the CatalogSource displays information regarding the missing ConfigMap.

b)

2. Add a ConfigMap object that the above CatalogSource refers to, make sure the fill the `data` section with invalid metadata that causes the registry pod to go into CrashLoop state. For example, you can put a non existing csv name for `currentCSV` inside the channel of the package.

Actual Results:
- The status block of the CatalogSource will have no information regarding the crash looping registry pod.

Expected Results:
- The status block of the CatalogSource displays information about the current state of the gRPC connection.

Comment 1 Evan Cordell 2019-08-27 14:43:09 UTC

*** This bug has been marked as a duplicate of bug 1737081 ***


Note You need to log in before you can comment on or make changes to this bug.