Bug 1866227 - [RFE] Add support for external_ids for OVS bridges and interfaces in libnm
Summary: [RFE] Add support for external_ids for OVS bridges and interfaces in libnm
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 8.3
Assignee: Thomas Haller
QA Contact: Vladimir Benes
URL:
Whiteboard:
Depends On:
Blocks: 1894575 1875967
TreeView+ depends on / blocked
 
Reported: 2020-08-05 06:29 UTC by Gris Ge
Modified: 2020-12-02 14:26 UTC (History)
11 users (show)

Fixed In Version: NetworkManager-1.30.0-0.3.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
Reproduce script (532 bytes, application/x-shellscript)
2020-08-05 06:30 UTC, Gris Ge
no flags Details

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


Note You need to log in before you can comment on or make changes to this bug.