Bug 1810025 - Missing status in the catalogSource
Summary: Missing status in the catalogSource
Status: CLOSED DUPLICATE of bug 1807128
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.5.0
Assignee: Evan Cordell
QA Contact: Jian Zhang
Depends On:
TreeView+ depends on / blocked
Reported: 2020-03-04 12:40 UTC by Petr Balogh
Modified: 2020-03-12 14:30 UTC (History)
0 users

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-03-12 14:30:15 UTC
Target Upstream Version:

Attachments (Terms of Use)
Logs of catalog sources (20.09 KB, application/gzip)
2020-03-04 12:40 UTC, Petr Balogh
no flags Details

Description Petr Balogh 2020-03-04 12:40:10 UTC
Created attachment 1667481 [details]
Logs of catalog sources

Description of problem:
From some reason there is missing status on every catalogSource object.

I see this issue on one of the deployment on VmWare done here:

We do add of custom catalog source for deployment of OCS and checking for READY state. But from some reason in this installation we do not see any status in any of the catalogsource. This actually failed our job for deployment of OCS.

On other deployment I have on AWS I see this part in yaml output for catalogsource:

    address: ocs-catalogsource.openshift-marketplace.svc:50051
    lastConnect: "2020-03-04T11:27:04Z"
    lastObservedState: READY
    createdAt: "2020-03-04T11:23:00Z"
    port: "50051"
    protocol: grpc
    serviceName: ocs-catalogsource
    serviceNamespace: openshift-marketplace

But this part is missing on every catalogsource from some reason.

Version-Release number of selected component (if applicable):

How reproducible:
Haven't tried to reproduce this yet.

Steps to Reproduce:
1. Install OCP 4.3 on Vmware
2. There is missing status under catalogSource

Actual results:
No status for any catalog source

Expected results:
See status of catalog source

Additional info:
Must gather logs:

Comment 1 Evan Cordell 2020-03-12 14:30:15 UTC
The logs for the catalog operator indicate that it could not start successfully:

2020-03-04T09:27:33.236516275Z time="2020-03-04T09:27:33Z" level=info msg="log level info"
2020-03-04T09:27:33.236516275Z time="2020-03-04T09:27:33Z" level=info msg="TLS keys set, using https for metrics"
2020-03-04T09:27:33.467714412Z time="2020-03-04T09:27:33Z" level=info msg="Using in-cluster kube client config"
2020-03-04T09:27:33.470530138Z time="2020-03-04T09:27:33Z" level=info msg="Using in-cluster kube client config"
2020-03-04T09:27:33.479522185Z time="2020-03-04T09:27:33Z" level=info msg="Using in-cluster kube client config"
2020-03-04T09:28:03.74109388Z time="2020-03-04T09:28:03Z" level=info msg="operator not ready: communicating with server failed: Get dial tcp i/o timeout"


There was a bug previously where this type of error would not cause the pod to fail, so the pod would hang indefinitely and not be reschedule to fix the problem.

This bug has since been fixed: 
4.5: https://bugzilla.redhat.com/show_bug.cgi?id=1807128
4.4: https://bugzilla.redhat.com/show_bug.cgi?id=1808418
4.3: https://bugzilla.redhat.com/show_bug.cgi?id=1808419

it should be rolled out in the next release of 4.3.

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

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