Bug 1809330

Summary: Changing bond mode from 1 to 5 fails
Product: Red Hat Enterprise Linux 8 Reporter: Dominik Holler <dholler>
Component: nmstateAssignee: Gris Ge <fge>
Status: CLOSED ERRATA QA Contact: Mingyu Shi <mshi>
Severity: urgent Docs Contact:
Priority: medium    
Version: 8.2CC: amusil, edwardh, ferferna, fge, jiji, jishi, jwboyer, mburman, mshi, mtessun, network-qe, till
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: nmstate-0.2.6-4.8.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 16:00:37 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:
Bug Depends On: 1810506, 1811389    
Bug Blocks: 1810550    
Attachments:
Description Flags
terminal log and nmstate files to reproduce
none
verification.log none

Description Dominik Holler 2020-03-02 21:02:21 UTC
Created attachment 1667073 [details]
terminal log and nmstate files to reproduce

Description of problem:
Changing bond mode from 1 to 5 fails

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. nmstatectl set 0_no_bond
2. nmstatectl set 1_initial_bond # create bond mode 1
3. nmstatectl set 2_changed_bond # try to create bond mode 5

Actual results:
Changing bond mode fails

Expected results:
Changing bond mode succeeds

Additional info:
Deleting the bond before applying the changed bond works.

Comment 1 Michael Burman 2020-03-03 09:41:34 UTC
Reproduced also when trying to switch from bond mode 4 to 5 or 6

Comment 2 Till Maas 2020-03-03 20:41:42 UTC
Dominik, is changing the bond mode a typical change that customers do? How important is it, that this is fixed in RHEL 8.2?

Comment 11 Gris Ge 2020-03-06 02:23:37 UTC
It will be an ugly fix in nmstate.

Ideally, with NetworkManager fixed their problem, no changed would be required in nmstate.

Comment 12 Gris Ge 2020-03-09 12:19:14 UTC
Found the root cause which is nmstate's fault.

Patch sent to upstream for review: https://github.com/nmstate/nmstate/pull/910

Comment 13 Gris Ge 2020-03-09 12:29:54 UTC
*** Bug 1811389 has been marked as a duplicate of this bug. ***

Comment 15 Dominik Holler 2020-03-09 13:20:23 UTC
Does the results from bug 1811389 means that the target release of the bug has to discussed again?
I think two NICs with the same MAC address are no acceptable state for layered products, because there is no comfortable workaround for users possible.

Comment 16 Michael Burman 2020-03-09 14:02:22 UTC
Raising severity as this is much worse and it's now affecting the MAC addresses of the slaves.

Comment 17 Gris Ge 2020-03-09 14:46:11 UTC
Patch been merged in upstream.


Downstream scratch build https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=27147692 passed CI tests.

The reason to request a blocker is this bug will left a system with multiple NIC sharing the same MAC address which could cause
terrible issues.

Comment 19 Till Maas 2020-03-09 15:13:29 UTC
(In reply to RHEL Program Management from comment #3)

> Answer the following 3 questions:
> 1. What is the impact of waiting until the next release to include this BZ? 
> Reviewers want to know which RHEL features or customers are affected and if
> it will impact any Layered Product or Hardware partner plans.

The underlying issue of having multiple network interfaces with the same MAC after removing a bond interface is very likely to break a lot of workflows.

> 2. What is the risk associated with the fix?  Reviewers want to know if the
> fix is contained, testable, and there is enough time to verify the work
> without impact the schedule or other commitments.

We tested the change upstream and also asked RHV to test the downstream test already including CI tests from Nmstate upstream and RHV/Vdsm.

> 3. Provide any other details that should be weighed in making a decision
> (Other releases affected, upstream status, business impacts, etc).

Everything is prepared for an immediate downstream release:
https://src.osci.redhat.com/rpms/nmstate/pull-request/4

Comment 23 Mingyu Shi 2020-03-10 09:18:56 UTC
nmstate-0.2.6-3.8.el8.noarch
NetworkManager-1.22.8-4.el8.x86_64

It works fine to switch among 7 modes, so does for creating bond with different modes. And after removing the bond, the slaves will get different MACs.
See the attachment for the details, it made switching modes at start, and then verified the MAC.

Comment 24 Mingyu Shi 2020-03-10 09:21:36 UTC
Created attachment 1668835 [details]
verification.log

Comment 25 Gris Ge 2020-03-13 03:17:55 UTC
nmstate-0.2.6-4.8.el8 fixed the regression for miimon=100 and MAC address issue.

Comment 27 errata-xmlrpc 2020-04-28 16:00:37 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.

https://access.redhat.com/errata/RHBA-2020:1696