This bug was initially created as a copy of Bug #1805444 I am copying this bug because: Description of problem: This was discovered in the investigation of https://bugzilla.redhat.com/show_bug.cgi?id=1793635 (for upgrades) The fix includes using the Multus "readinessindicatorfile". How reproducible: During upgrades.
PR @ https://github.com/openshift/multus-cni/pull/47 I think the only validation that can be done would be to spin up a cluster that includes that PR and enter the Multus damonset and see if the file /entrypoint.sh contains the string MULTUS_READINESS_INDICATOR_FILE if that's the case, I believe it should be (mostly) verified -- that code won't be exercised until the associate CNOs merge (and they can't pass CI until that code is there, e.g. that string I mentioned)
Tested and verified in 4.4.0-0.nightly-2020-02-25-085441 [root@dhcp-41-193 FILE]# oc exec -it multus-2jh6t -- cat /entrypoint.sh | grep MULTUS_READINESS_INDICATOR_FILE MULTUS_READINESS_INDICATOR_FILE="" echo -e "\t--readiness-indicator-file=$MULTUS_READINESS_INDICATOR_FILE (used only with --multus-conf-file=auto)" MULTUS_READINESS_INDICATOR_FILE=$VALUE if [ ! -z "${MULTUS_READINESS_INDICATOR_FILE// }" ]; then READINESS_INDICATOR_FILE_STRING="\"readinessindicatorfile\": \"$MULTUS_READINESS_INDICATOR_FILE\"," [root@dhcp-41-193 FILE]# oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.4.0-0.nightly-2020-02-25-085441 True False 26m Cluster version is 4.4.0-0.nightly-2020-02-25-085441 [root@dhcp-41-193 FILE]#
(In reply to Weibin Liang from comment #5) > Tested and verified in 4.4.0-0.nightly-2020-02-25-085441 > > [root@dhcp-41-193 FILE]# oc exec -it multus-2jh6t -- cat /entrypoint.sh | > grep MULTUS_READINESS_INDICATOR_FILE > MULTUS_READINESS_INDICATOR_FILE="" > echo -e "\t--readiness-indicator-file=$MULTUS_READINESS_INDICATOR_FILE > (used only with --multus-conf-file=auto)" This confirms that the option *exists* in multus, but if you look at the multus Pod spec, we weren't actually passing that option to it yet, so it had no effect.
*** Bug 1794142 has been marked as a duplicate of this bug. ***
Tested and verified in 4.4.0-0.nightly-2020-03-02-081928 [root@dhcp-41-193 FILE]# oc describe daemonset.apps/multus | grep readiness-indicator-file --readiness-indicator-file=/var/run/multus/cni/net.d/10-ovn-kubernetes.conf [root@dhcp-41-193 FILE]# oc describe pod multus-hfv8r | grep readiness-indicator-file --readiness-indicator-file=/var/run/multus/cni/net.d/10-ovn-kubernetes.conf
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-2020:0581
Removing UpgradeBlocker from this older bug, to remove it from the suspect queue described in [1]. If you feel like this bug still needs to be a suspect, please add keyword again. [1]: https://github.com/openshift/enhancements/pull/475