We are chasing failures that started in https://amd64.ocp.releases.ci.openshift.org/releasestream/4.10.0-0.nightly/release/4.10.0-0.nightly-2021-10-10-115047 that went to zero percent success for upgrading operators. timing is a likely difference, and this stands out a very different timing. Please explain why this zero seconds is expected.
see https://amd64.ocp.releases.ci.openshift.org/#4.10.0-0.nightly. One aggregated run that failed is https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/aggregated-aws-sdn-upgrade-4.10-micro-release-openshift-release-analysis-aggregator/1447173360613068800 and a particular failed run is https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-release-master-nightly-4.10-e2e-aws-upgrade/1447169497659084800
Verified using IPI on AWS version: $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.11.0-0.nightly-2022-05-25-193227 True False 25m Cluster version is 4.11.0-0.nightly-2022-05-25-193227 1) Applying a normal machine config without .spec.osImageURL we these events $ oc get events --sort-by metadata.creationTimestamp -n default 6m30s Normal OSUpdateStarted node/ip-10-0-148-222.us-east-2.compute.internal 6m30s Normal OSUpgradeSkipped node/ip-10-0-148-222.us-east-2.compute.internal OS upgrade skipped; new MachineConfig (rendered-worker-f76639fa4be51dc1fbc649d97ca6f55d) has same OS image (quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:abc529fd4bf0f9208c5222e393e05997205da03f47ca413184112897a23db9ee) as old MachineConfig (rendered-worker-c2caa9cafb8e19eb33468007b65f5d52) 6m30s Normal OSUpdateStaged node/ip-10-0-148-222.us-east-2.compute.internal Changes to OS staged 2) Applying an upgrade to 4.11.0-0.nightly-2022-06-01-200905 we get these events $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.11.0-0.nightly-2022-06-01-200905 True False 96s Cluster version is 4.11.0-0.nightly-2022-06-01-200905 $ oc get events --sort-by metadata.creationTimestamp -n default 19m Normal OSUpdateStarted node/ip-10-0-148-222.us-east-2.compute.internal Upgrading OS 19m Normal OSUpgradeApplied node/ip-10-0-148-222.us-east-2.compute.internal OS upgrade applied; new MachineConfig (rendered-worker-4e878a2249f2541265237af6645abea9) has new OS image (quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:3a6e70ae5c1d2da57f286ac9cdd0df38c45dff500c46d553187344a9d338bbd0) 19m Normal OSUpdateStaged node/ip-10-0-148-222.us-east-2.compute.internal Changes to OS staged We move the issue to VERIFIED status.
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