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: NetworkManagerAssignee: Thomas Haller <thaller>
Status: CLOSED ERRATA QA Contact: Vladimir Benes <vbenes>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.3CC: acardace, atragler, bgalvani, bsanford, jmaxwell, lrintel, rkhan, sukulkar, thaller, till, vbenes
Target Milestone: rcKeywords: 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 Flags
Reproduce script none

Description Gris Ge 2020-08-05 06:29:37 UTC
Description of problem:

When activating a ovs interface connection/profile via `nmcli c up`,
the OVS database customization will be removed.

Version-Release number of selected component (if applicable):
NetworkManager-1.26.0-0.2.el8.x86_64
openvswitch2.13-2.13.0-39.el8fdp.x86_64

How reproducible:
100%

Steps to Reproduce:
1. sudo ./ovs_bug.sh
2.
3.

Actual results:

After `nmcli c up ovs0`, the ovsdb lose `foo:boo` external_ids

Expected results:

The ovsdb still has `foo:boo` in external_ids

Additional info:

The command 
sudo ovs-ofctl mod-port br0 ovs0 down
can bring a ovs interface down without losing database information.

Comment 1 Gris Ge 2020-08-05 06:30:07 UTC
Created attachment 1710471 [details]
Reproduce script

Comment 2 Gris Ge 2020-08-05 06:31:17 UTC
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"}

```

Comment 3 Thomas Haller 2020-08-05 08:54:53 UTC
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.

Comment 4 Gris Ge 2020-08-05 09:14:08 UTC
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).

Comment 5 Gris Ge 2020-09-22 04:32:21 UTC
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?

Comment 6 Antonio Cardace 2020-09-22 14:20:03 UTC
Hi Gris,

we decided that NM will support external_ids modifications.

Comment 11 Thomas Haller 2020-11-19 08:52:05 UTC
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

Comment 16 Vladimir Benes 2020-12-02 14:26:40 UTC
and all arches went well in CI -> VERIFIED

Comment 18 errata-xmlrpc 2021-05-18 13:29: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 (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