NM should ideally use ofport_request to make sure that port IDs remain stable, see: https://docs.openvswitch.org/en/latest/tutorials/ovs-advanced/

Example of how the port id changes from `6(ens5): addr:0e:5e:00:0a:14:47` to `7(ens5): addr:0e:5e:00:0a:14:47`:
~~~
[root@ip-10-0-155-59 tmp]# ovs-ofctl show br-ex
OFPT_FEATURES_REPLY (xid=0x2): dpid:00000e5e000a1447
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 3(patch-br-ex_ip-): addr:5e:f1:2f:35:7d:ef
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 6(ens5): addr:0e:5e:00:0a:14:47
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-ex): addr:0e:5e:00:0a:14:47
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
[root@ip-10-0-155-59 tmp]# systemctl stop NetworkManager
[root@ip-10-0-155-59 tmp]# ovs-ofctl show br-ex
OFPT_FEATURES_REPLY (xid=0x2): dpid:00000e5e000a1447
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 3(patch-br-ex_ip-): addr:5e:f1:2f:35:7d:ef
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 6(ens5): addr:0e:5e:00:0a:14:47
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
[root@ip-10-0-155-59 tmp]# ip link ls dev ens5
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000
    link/ether 0e:5e:00:0a:14:47 brd ff:ff:ff:ff:ff:ff
[root@ip-10-0-155-59 tmp]# systemctl start NetworkManager
[root@ip-10-0-155-59 tmp]# 
[root@ip-10-0-155-59 tmp]# ovs-ofctl show br-ex
OFPT_FEATURES_REPLY (xid=0x2): dpid:00000e5e000a1447
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 3(patch-br-ex_ip-): addr:5e:f1:2f:35:7d:ef
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 7(ens5): addr:0e:5e:00:0a:14:47
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-ex): addr:0e:5e:00:0a:14:47
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
~~~

Created attachment 1858962 [details]
dispatcher pre-up script + analysis

I created a dispatcher pre-up script which sets a fix ovs port id. Ideally, NM would have an option so that we can pre-assign an ovs port id. As you can see from the logs, there still is a 1 second ga

> Ideally, NM would have an option so that we can pre-assign an ovs port id

I think that's a reasonable requirement.

> What reason is there for deleting the ports completely and recreating them? 

The reason is that there is a duplication of persistent state when a OVS connection is created by NM. NM maintains its own state based on active connections and at the same time it needs to write that state to the ovsdb. Upon shutdown, NM needs to clean up ovsdb so that those interfaces are not created automatically by ovs at the next boot, because NM should be in control of which connections are activated.

> The impact is way too big, instead a smart solution would be to compare the desired state to the current state and only make those changes that are really necessary.

I agree that this would be the optimal solution, but it seems hard to implement correctly.

Awesome, thank you so much for the answer. Let's go with that option then which will allow us to pre-assign an ovs port id. Meanwhile, in our case, we are going to work around this with a dispatcher pre-up script.

Thanks!

i am now working on this

fixed upstream by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/db88bc50905f7f4ad61c81a4b7541279e7a92cca
in NetworkManager 1.41.2+

(changing status to ASSIGNED because the patch is not yet backported to nm-1-40)

we have the nmcli_add_openvswitch_ofport_request test running in centos and in RHEL automation too, passing

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 (NetworkManager 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/RHBA-2023:2485