Description of problem: Installed 4.0.0-0.alpha-2019-03-12-143341 Upgraded to 4.0.0-0.alpha-2019-03-12-153711 During cluster upgrade, the network operator reported unavailable. It appeared to report unavailable when a master machine is rebooted. Opening this bug to determine if available=false should occur during a machine reboot. The network did upgrade, but available toggled. Expected results: Available should not go false during an upgrade.
this is the next reason we will fail upgrade tests as we try to ensure no operator goes unavailable during upgrades. https://github.com/openshift/cluster-network-operator/blob/f4ef74c2d9179c7ccfecafb846f3fc800de01223/pkg/controller/statusmanager/status_manager.go#L239 this appears like problematic logic as the way i understand the flow, if the network operator is progressing to a new version it reports unavailable, even though a network is obviously available during the rollout across release versions.
see sample upgrade job runs: https://deck-ci.svc.ci.openshift.org/?job=release-openshift-origin-installer-e2e-aws-upgrade-4.0 https://deck-ci.svc.ci.openshift.org/log?job=release-openshift-origin-installer-e2e-aws-upgrade-4.0&id=97 "version changed Failing to True: ClusterOperatorNotAvailable: Cluster operator network is still updating"
To danw. So, we should be setting "available=true progressing=true"? What is the expected state as the daemonset updates roll out?
Verified this bug when upgraded from 4.0.0-0.nightly-2019-03-15-063749 to 4.0.0-0.nightly-2019-03-18-200009 The AVAILABLE still be 'True' during upgrade.
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