I ran into this issue while testing the fix for bug 2027008. The PR that introduced the regression passed e2e-operator just fine: https://github.com/openshift/local-storage-operator/pull/298 But the PR that fixes that regression continues to fail e2e-operator: https://github.com/openshift/local-storage-operator/pull/301 The problem is that the e2e-operator test always pulls the LSO image from quay.io/openshift/origin-local-storage-operator, instead of using the CI build. https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_local-storage-operator/301/pull-ci-openshift-local-storage-operator-master-e2e-operator/1468896840685457408/artifacts/e2e-operator/gather-extra/artifacts/events.json "message": "Successfully pulled image \"quay.io/openshift/origin-local-storage-operator\" in 4.64993059s", CI is configured to run `make test_e2e` here: https://github.com/openshift/release/blob/cb57f9bab7dc764185f1a2c3a79f89698f46f5ea/ci-operator/config/openshift/local-storage-operator/openshift-local-storage-operator-master.yaml#L71 Which runs `./hack/test-e2e.sh`: https://github.com/openshift/local-storage-operator/blob/8fc42cc8b990907c88a6da551dc85b55c2dc4417/Makefile#L261-L262 And in `./hack/test-e2e.sh` we default to using the quay images if there is no image provided: https://github.com/openshift/local-storage-operator/blob/8fc42cc8b990907c88a6da551dc85b55c2dc4417/hack/test-e2e.sh#L15-L16 Looking back at the CI job, we can see those env vars getting set in the build log: https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_local-storage-operator/301/pull-ci-openshift-local-storage-operator-master-e2e-operator/1468896840685457408/build-log.txt + IMAGE_LOCAL_STORAGE_OPERATOR=quay.io/openshift/origin-local-storage-operator + IMAGE_LOCAL_DISKMAKER=quay.io/openshift/origin-local-storage-diskmaker Do we just need to define those environment variables here? https://github.com/openshift/release/blob/cb57f9bab7dc764185f1a2c3a79f89698f46f5ea/ci-operator/config/openshift/local-storage-operator/openshift-local-storage-operator-master.yaml#L65-L76 And if so... how do we extract the name of the image that was created by CI?
From the following pod info[1], it uses the ci image not upstream one. "image": "registry.build01.ci.openshift.org/ci-op-0x7p6lit/pipeline@sha256:a0d36c7382267e0b2789066af0fa4de792bbcf64a09f1374a22f62e19889a364", "imagePullPolicy": "IfNotPresent", "name": "local-storage-operator", From the event[2], the ci image is pulled "lastTimestamp": "2022-03-01T15:02:44Z", "message": "Successfully pulled image \"registry.build01.ci.openshift.org/ci-op-0x7p6lit/pipeline@sha256:a0d36c7382267e0b2789066af0fa4de792bbcf64a09f1374a22f62e19889a364\" in 5.089955108s", but a bit strange that the upstream image is also used somewhere? And it is in default ns. "lastTimestamp": "2022-03-01T15:05:34Z", "message": "Successfully pulled image \"quay.io/openshift/origin-local-storage-operator\" in 4.443709141s", "metadata": { "creationTimestamp": "2022-03-01T15:05:34Z", "name": "local-storage-operator-577fddbf77-69792.16d84a18cdf8d835", "namespace": "default", "resourceVersion": "31264", "uid": "a38be354-5b2a-462d-9041-cb094e916ac9" [1] https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_local-storage-operator/327/pull-ci-openshift-local-storage-operator-master-e2e-operator/1498661877167689728/artifacts/e2e-operator/gather-extra/artifacts/pods.json [2] https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_local-storage-operator/327/pull-ci-openshift-local-storage-operator-master-e2e-operator/1498661877167689728/artifacts/e2e-operator/gather-extra/artifacts/events.json I understand our CI tested in openshift-local-storage ns and I'd like to update status as "Verified".
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 (Important: OpenShift Container Platform 4.11.0 bug fix and security update), 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/RHSA-2022:5069