Bug 2012969

Summary: need to figure out why osupdatedstart to reboot is zero seconds
Product: OpenShift Container Platform Reporter: David Eads <deads>
Component: Machine Config OperatorAssignee: Zack Zlotnik <zzlotnik>
Machine Config Operator sub component: Machine Config Operator QA Contact: Rio Liu <rioliu>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: medium CC: aos-bugs, kgarriso, mkrejci, skumari, sregidor, zzlotnik
Version: 4.10   
Target Milestone: ---   
Target Release: 4.11.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-08-10 10:38:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Eads 2021-10-11 18:09:27 UTC
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.

Comment 9 Sergio 2022-06-03 10:39:56 UTC
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.

Comment 11 errata-xmlrpc 2022-08-10 10:38:04 UTC
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