Is there any chance there are two catalog operator pods running (anywhere in the cluster)? I have seen this issue when we accidentally had two catalog operators running at once. I moved the severity to low since InstallPlan application is idempotent (no errors will occur from having two created for you)
Evan, No, only one catalog operator running at that time. > I moved the severity to low since InstallPlan application is idempotent (no errors will occur from having two created for you) Yes, no errors. But, it's confusing for users. I think we should find the root cause and fix it although it's a little problem.
I encounter this issue again, details: [root@qe-jiazha-311-gce-1-master-etcd-1 ~]# oc get subscription NAME PACKAGE SOURCE CHANNEL mongodb-enterprise-qss5n mongodb-enterprise certified-operators preview [root@qe-jiazha-311-gce-1-master-etcd-1 ~]# oc get installplan NAME CSV SOURCE APPROVAL APPROVED install-mongodboperator.v0.3.2-722mp mongodboperator.v0.3.2 certified-operators Automatic false install-mongodboperator.v0.3.2-hfzq6 mongodboperator.v0.3.2 certified-operators Automatic false Only one catalog operator running. [root@qe-jiazha-311-gce-1-master-etcd-1 ~]# oc get pods -n operator-lifecycle-manager NAME READY STATUS RESTARTS AGE catalog-operator-76c846684c-pm4n9 1/1 Running 0 1h olm-operator-5b7f7c4556-qwfhm 1/1 Running 0 1h [root@qe-jiazha-311-gce-1-master-etcd-1 ~]# oc get csv NAME DISPLAY VERSION REPLACES PHASE mongodboperator.v0.3.2 MongoDB 0.3.2 Succeeded [root@qe-jiazha-311-gce-1-master-etcd-1 ~]# oc get pods NAME READY STATUS RESTARTS AGE mongodb-enterprise-operator-7b7b8b9889-67trr 1/1 Running 0 1m
What about `oc get pods --all-namespaces`? I'm concerned there might be a catalog operator in another namespace somehow.
Evan, No, only one catalog-operator running in the cluster: [root@share-wmenghaglb3116-mez-1 ~]# oc get pods --all-namespaces | grep catalog-operator operator-lifecycle-manager catalog-operator-76c846684c-r6h6m 1/1 Running 0 50m [root@share-wmenghaglb3116-mez-1 ~]# oc get pods --all-namespaces | grep operator jian etcd-operator-7b49974f5b-5j9lf 3/3 Running 0 17m jian3 etcd-operator-7b49974f5b-k5k6w 3/3 Running 0 42s openshift-monitoring cluster-monitoring-operator-75c6b544dd-npkxx 1/1 Running 0 1d openshift-monitoring prometheus-operator-564dd668b-8t6cf 1/1 Running 0 1d operator-lifecycle-manager catalog-operator-76c846684c-r6h6m 1/1 Running 0 47m operator-lifecycle-manager olm-operator-5b7f7c4556-wg89n 1/1 Running 0 47m [root@share-wmenghaglb3116-mez-1 ~]# oc get subscription -n jian3 NAME PACKAGE SOURCE CHANNEL etcd-v58f8 etcd rh-operators alpha Two installplan created by the same subscription: [root@share-wmenghaglb3116-mez-1 ~]# oc get installplan -n jian3 NAME CSV SOURCE APPROVAL APPROVED install-etcdoperator.v0.9.2-7w9mg etcdoperator.v0.9.2 rh-operators Automatic false install-etcdoperator.v0.9.2-gq2b9 etcdoperator.v0.9.2 rh-operators Automatic false [root@share-wmenghaglb3116-mez-1 ~]# oc get csv -n jian3 NAME DISPLAY VERSION REPLACES PHASE etcdoperator.v0.9.2 etcd 0.9.2 etcdoperator.v0.9.0 Succeeded [root@share-wmenghaglb3116-mez-1 ~]# oc get pods -n jian3 NAME READY STATUS RESTARTS AGE etcd-operator-7b49974f5b-k5k6w 3/3 Running 0 2m [root@share-wmenghaglb3116-mez-1 ~]# oc get pods NAME READY STATUS RESTARTS AGE catalog-operator-76c846684c-r6h6m 1/1 Running 0 51m olm-operator-5b7f7c4556-wg89n 1/1 Running 0 51m [root@share-wmenghaglb3116-mez-1 ~]# oc rsh olm-operator-5b7f7c4556-wg89n sh-4.2$ olm -version OLM version: 0.6.0 git commit: 3df6bea image: registry.reg-aws.openshift.com:443/openshift3/ose-operator-lifecycle-manager:v3.11 imageID: docker-pullable://registry.reg-aws.openshift.com:443/openshift3/ose-operator-lifecycle-manager@sha256:a706b51ae87dc9faa98b484ab06bf8ad2f4c3283de0c024b253f273c981318cc
It seems like a bug then, but I've moved it to 4.0 since it doesn't affect users at all.
*** Bug 1633885 has been marked as a duplicate of this bug. ***
I don't encounter this issue anymore for a long by using the OLM in OCP 4.0. So, verify it. Please feel free to reopen it if you encounter this issue. Current version: mac:aws-ocp jianzhang$ oc exec olm-operator-5fdc6d559f-2x7zp -- olm -version OLM version: 0.8.0 git commit: c53c51a
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-2019:0758