Has this issue been seen on a 4.2 cluster before? Do we still have one available for investigation?

Moving to 4.3 as not overly concerned that this is a primary customer use case.

Hi, Nick

Yes, it only occurred in the cluster which one of the nodes located in Yizhuang District, Beijing. 

Per comment 5, 
> But, after I reschedule the package pods on this new worker, it failed to get the packagemanifests. Is it as expected? @Evan
mac:~ jianzhang$ oc get pods  -o wide
NAME                               READY   STATUS    RESTARTS   AGE     IP            NODE                                      NOMINATED NODE   READINESS GATES
catalog-operator-dbf74866f-9mgvr   1/1     Running   0          5h23m   10.129.0.25   qe-wewang-https3-w49n7-control-plane-0    <none>           <none>
olm-operator-5bd79c59ff-cfsnj      1/1     Running   0          5h23m   10.129.0.29   qe-wewang-https3-w49n7-control-plane-0    <none>           <none>
packageserver-55ccd876d6-5dhsl     1/1     Running   0          85s     10.129.2.8    dell-per630-04.rhts.eng.pek2.redhat.com   <none>           <none>
packageserver-55ccd876d6-hc4sl     1/1     Running   0          2m39s   10.129.2.7    dell-per630-04.rhts.eng.pek2.redhat.com   <none>           <none>
mac:~ jianzhang$ oc get packagemanifest
Error from server (Timeout): the server was unable to return a response in the time allotted, but may still be processing the request (get packagemanifests.packages.operators.coreos.com)
mac:~ jianzhang$ oc logs packageserver-55ccd876d6-5dhsl 
Error from server: Get https://10.73.2.5:10250/containerLogs/openshift-operator-lifecycle-manager/packageserver-55ccd876d6-5dhsl/packageserver: proxyconnect tcp: x509: certificate signed by unknown authority
But, after the package pods rescheduled to the master, it works well, LGTM.


Do you think is it an issue? If not, I think I can verify it.

Hi, Nick

I'm not sure what's the difference. But, we did always met this issue in that cluster, which "run a worker in Yizhuang District, Beijing". The system of that worker is RHEL 7.7, not the RHCOS. But, it's OK now, verify it, thanks!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0062