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

CI test added:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/675

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