Bug 1809285

Summary: [4.4] Multus should not cause machine to go not ready when Multus is updated
Product: OpenShift Container Platform Reporter: Douglas Smith <dosmith>
Component: NetworkingAssignee: Douglas Smith <dosmith>
Networking sub component: multus QA Contact: Weibin Liang <weliang>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: jeder, weliang
Version: 4.4   
Target Milestone: ---   
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: 1809283
: 1809289 (view as bug list) Environment:
Last Closed: 2020-05-04 11:43:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1809289    
Bug Blocks: 1809283    

Description Douglas Smith 2020-03-02 19:09:53 UTC
+++ This bug was initially created as a clone of Bug #1809283 +++

Description of problem: When Multus is upgraded it invalidates the primary CNI configuration on each node as it is upgraded. This causes unnecessary delays, and can result

How reproducible: During upgrades.

Additional info: One of the fixes for https://bugzilla.redhat.com/show_bug.cgi?id=1793635

--- Additional comment from Douglas Smith on 2020-03-02 19:09:00 UTC ---

PR @ https://github.com/openshift/multus-cni/pull/52

Comment 3 Weibin Liang 2020-03-05 20:06:38 UTC
Tested and verified in 4.4.0-0.nightly-2020-03-05-100046

[root@dhcp-41-193 Network]# oc exec multus-5k5jr -- cat /entrypoint.sh | grep invalid
[root@dhcp-41-193 Network]# oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.4.0-0.nightly-2020-03-05-100046   True        False         5h23m   Cluster version is 4.4.0-0.nightly-2020-03-05-100046
[root@dhcp-41-193 Network]# 

Without fixed PR, cat /entrypoint.sh will show:
[root@dhcp-41-193 FILE]# oc exec multus-fp4rb -- cat /entrypoint.sh | grep invalid
        {Multus configuration intentionally invalidated to prevent pods from being scheduled.}
      log "Multus configuration intentionally invalidated to prevent pods from being scheduled."
          # But first, check if it has the invalidated configuration in it (otherwise we keep doing this over and over.)
          if ! grep -q "invalidated" $CNI_CONF_DIR/00-multus.conf; then

Comment 5 errata-xmlrpc 2020-05-04 11:43:52 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, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.