Bug 1866227
Summary: | [RFE] Add support for external_ids for OVS bridges and interfaces in libnm | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Gris Ge <fge> | ||||
Component: | NetworkManager | Assignee: | Thomas Haller <thaller> | ||||
Status: | CLOSED ERRATA | QA Contact: | Vladimir Benes <vbenes> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 8.3 | CC: | acardace, atragler, bgalvani, bsanford, jmaxwell, lrintel, rkhan, sukulkar, thaller, till, vbenes | ||||
Target Milestone: | rc | Keywords: | FutureFeature, Triaged | ||||
Target Release: | 8.3 | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | NetworkManager-1.30.0-0.3.el8 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2021-05-18 13:29: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: | |||||||
Bug Blocks: | 1875967, 1894575 | ||||||
Attachments: |
|
Description
Gris Ge
2020-08-05 06:29:37 UTC
Created attachment 1710471 [details]
Reproduce script
Output of above script: ``` + nmcli c add type ovs-bridge ifname br0 connection.id br0 Warning: There are 3 other connections with the name 'br0'. Reference the connection by its uuid '33267736-2af6-4dc4-8158-a6eb435e5dcb' Connection 'br0' (33267736-2af6-4dc4-8158-a6eb435e5dcb) successfully added. + nmcli c add type ovs-port ifname ovs-port-ovs0 master br0 connection.id ovs-port-ovs0 Warning: There are 3 other connections with the name 'ovs-port-ovs0'. Reference the connection by its uuid '5ab738f1-d980-4dcc-ad1b-f99471e6d9ef' Connection 'ovs-port-ovs0' (5ab738f1-d980-4dcc-ad1b-f99471e6d9ef) successfully added. + nmcli c add type ovs-interface ifname ovs0 slave-type ovs-port master ovs-port-ovs0 ipv4.method disabled ipv6.method disabled connection.id ovs0 Warning: There are 3 other connections with the name 'ovs0'. Reference the connection by its uuid '67192a39-90cc-4562-82f7-7affd75b1ae5' Connection 'ovs0' (67192a39-90cc-4562-82f7-7affd75b1ae5) successfully added. + ovs-vsctl set Interface ovs0 external-ids:foo=boo + ovs-vsctl --columns=name,external-ids list Interface name : ovs0 external_ids : {NM.connection.uuid="ab0df571-469a-4c72-830d-01b4b9bfbc51", foo=boo} + nmcli c down ovs0 Connection 'ovs0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/19) + nmcli c up ovs0 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/21) + sudo ovs-vsctl --columns=name,external-ids list Interface name : ovs0 external_ids : {NM.connection.uuid="ab0df571-469a-4c72-830d-01b4b9bfbc51"} ``` among the core things that NetworkManager does is providing a way to persist network configuration. If you configure external-ids in ovsdb, then this bypasses NetworkManager (and its persistence mechanism). Of course, if NetworkManager activates the profile the next time, the information you added is lost, because you didn't persist it. You were apparently willing to configure this information in a volatile manner (after NetworkManager activated the profile). If you do that, you will need to do that also in the future, when NetworkManager activates the profile again. The real solution is not to bypass NetworkManager's API if you want that the setting gets persisted (via the mechanism that NetworkManager has: NM connection profiles). > The command > sudo ovs-ofctl mod-port br0 ovs0 down > can bring a ovs interface down without losing database information. ovsdb indeed is also a persistent storage of configuration. However, since already NetworkManager persists the configuration, this duplication is undesirable, and NetworkManager clean up the configuration once it's no longer useful. Leaving it there means a complicated two way synchronization which sounds like a bad idea. IOW, ovsdb persists configuration too, but when you use NetworkManager, then the primary configuration lies with NetworkManager. Maybe that could be changed, however that requires more thought and good use-cases what it even would mean to keep the configuration duplicated and how to merge it. This is related to https://bugzilla.redhat.com/show_bug.cgi?id=1861296. The use case is customer external-ids for OVS bridge and OVS interface. https://www.ovirt.org/develop/release-management/features/network/provider-physical-network.html Quote: VDSM: Localnet port is attached to an abstract network name. This name is mapped to an OVS bridge name on each host via OVS DB attribute external-ids:ovn-bridge-mappings. This attribute is configured after each setupNetworks command and during upgrades (after reboot or upgrade of vdsm package). Hi Antonio, What do we want to change for this bug? Will NM keep unknown/unmanaged config in ovsdb or NM will support external_ids modifications via libnm? Hi Gris, we decided that NM will support external_ids modifications. Upstream work: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/673 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/679 Note that nmcli support was not (yet) added. That makes it slightly cumbersome to test this. As workaround, use the example script [1] for inspecting/modifying the ovs-external-ids. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/adaeb7a872ce7c1b934de441d4db19c49973aeac/examples/python/gi/ovs-external-ids.py and all arches went well in CI -> VERIFIED 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 (Moderate: NetworkManager and libnma security, bug fix, and enhancement update), 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/RHSA-2021:1574 |