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: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> | ||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.6 | CC: | 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
Edward Haas
2019-04-29 08:40:07 UTC
Seems like Device.Reapply() doesn't normalize input connection. 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 Fixed upstream by: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb5038defccfe02699f1eafd3ef505fe2aba2d27 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
(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. The reproducer above works for bond and non-assumed ethernet connections. Since assumed connections are special case, verifying the bug. Is this issue resolved? Why is the BZ still open? (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. 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 |