Bug 1703960

Summary: Device.Reapply() fails if wired setting have not been explicitly set
Product: Red Hat Enterprise Linux 7 Reporter: Edward Haas <edwardh>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.6CC: atragler, bgalvani, fgiudici, fpokryvk, lrintel, rkhan, sukulkar, thaller, till, vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-1.18.4-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-31 20:07:59 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:
Attachments:
Description Flags
reproducer in python for ethernet device none

Description Edward Haas 2019-04-29 08:40:07 UTC
Description of problem:
While attempting to use `reapply` in the Nmstate project, we have found that in case the wired setting is not defined/added to the new profile, the reapply operation will fail, claiming that the mac address change is not supported.

`nm-device-error-quark: Can't reapply changes to '802-3-ethernet.cloned-mac-address' setting (3)`

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


How reproducible:


Steps to Reproduce:
1. Fetch existing profile using `get_connection_by_id`.
2. Create new profile using SimpleConnection.new()
3. Add to the new profile the wanted setting (connection and IPvX in our case) using `add_setting`. (do not include the wired setting)
4. Replace existing profile settings with the new profile setting using `replace_settings_from_connection(new_profile)`.
5. Commit the existing profile changes using `commit_changes_async`.
7. Execute reapply with the existing profile.

Actual results:
Step 7 fails with the following error:
`nm-device-error-quark: Can't reapply changes to '802-3-ethernet.cloned-mac-address' setting (3)`

Expected results:
Reapply should succeed because no wired changes have been requested.

Additional info:
Workaround: 
Fetching the wired setting from the current profile and using it in the new profile has resolved the problem.

Comment 2 Edward Haas 2019-04-29 08:41:52 UTC
Seems like Device.Reapply() doesn't normalize input connection.

Comment 3 Beniamino Galvani 2019-05-25 16:20:33 UTC
The root cause is that the ifcfg-rh settings plugin adds an empty wired setting when saving and reloading a bond/bridge/team connection. The patch at [1] should fix this issue.

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/166

Comment 7 Filip Pokryvka 2019-10-21 12:20:16 UTC
Created attachment 1627660 [details]
reproducer in python for ethernet device

run these commands before python script:

nmcli con add type ethernet con-name testeth2 ifname eth2
nmcli device diconnect eth2
ip a add 192.168.5.5/24 dev eth2

Comment 8 Beniamino Galvani 2019-10-22 19:49:42 UTC
(In reply to Filip Pokryvka from comment #7)
> Created attachment 1627660 [details]
> reproducer in python for ethernet device
> 
> run these commands before python script:
> 
> nmcli con add type ethernet con-name testeth2 ifname eth2
> nmcli device diconnect eth2
> ip a add 192.168.5.5/24 dev eth2

I tried this and the reapply fails with error:

  Can't reapply changes to '802-3-ethernet.mac-address' setting (3)

because the assumed connection on eth2 has ethernet.mac-address set while the new connection doesn't have it. NM computes the difference between the connection currently active and the one to reapply and finds that ethernet.mac-address changed, but that isn't a property that can be reapplied at runtime. This sounds correct in my opinion.

Comment 9 Filip Pokryvka 2019-10-23 13:21:54 UTC
The reproducer above works for bond and non-assumed ethernet connections. Since assumed connections are special case, verifying the bug.

Comment 10 Edward Haas 2020-01-22 14:42:36 UTC
Is this issue resolved? Why is the BZ still open?

Comment 11 Beniamino Galvani 2020-03-02 09:15:38 UTC
(In reply to Edward Haas from comment #10)
> Is this issue resolved? Why is the BZ still open?

There are multiple issues related to reapplying an optional
setting.

The first one is that the wired setting was implicitly added by NM
when saving some connection types (bridges, bonds, etc.), and so if
you tried to reapply the same connection again without changes, NM
would complain because the new connection didn't have a wired setting
while the old one did. This issue was solved in this bz.

The other issue is that at the moment NM refuses to perform a reapply
if the new connection adds a wired setting with all default values (or
if it removes it and it was all defaults previously).

For the wired setting, a missing setting and one with all defaults is
equivalent; but this is not true for other settings. For example, a
missing sriov setting means not to touch SR-IOV related parameters;
while a sriov setting with default values (zero VFs) means to reset
VFs. So we need to implement a setting-specific comparison logic.

Comment 13 errata-xmlrpc 2020-03-31 20:07:59 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:1162