Bug 1660250

It appears that the errors that appeared when starting the bridge through nmcli were because I didn't restart NetworkManager after installing NetworkManager-ovs RPM. I'm now investigating to see if the other errors are also cleared up now that I have restarted NetworkManager.

Shouldn't the NetworkManager-ovs package cause the NewtorkMangaer service to be restarted (along with other packages that require NetworkManager to restart)?

It appears I still can't add an OVS bridge using nmstatecli. If I create a very simple bridge, it appears to work, it even creates a bridge, but when I bring it up it doesn't appear in "ovs-vsctl show".

[dsneddon@localhost nmstate_configs]$ cat ovs_bridge_simple.yaml 
interfaces:
- name: ovs-br0
  type: ovs-bridge
  state: up
  bridge:
    options:
      fail-mode: ''
      mcast-snooping-enable: false
      rstp: false
      stp: true

[dsneddon@localhost nmstate_configs]$ sudo nmstatectl set < ovs_bridge_simple.yaml 
2018-12-17 16:30:53,947 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/4 created for all devices: 60
2018-12-17 16:30:53,948 root         DEBUG    Connection settings for create_setting:
id: ovs-br0
iface: ovs-br0
uuid: bb00ac99-696f-4fb1-8f53-a8d5daac5710
type: ovs-bridge
autoconnect: False
autoconnect_slaves: <enum NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_NO of type NM.SettingConnectionAutoconnectSlaves>
2018-12-17 16:30:53,952 root         DEBUG    Executing NM action: func=add_connection_async, args=(<NM.SimpleConnection object at 0x7f001210ff00 (NMSimpleConnection at 0x55612f6a5fa0)>, True, <Gio.Cancellable object at 0x7f00121c42d0 (GCancellable at 0x7f000c050820)>, <function _add_connection_callback at 0x7f001251ae60>, <libnmstate.nm.nmclient._MainLoop object at 0x7f0012147c90>)
2018-12-17 16:30:53,961 root         DEBUG    Connection adding succeeded: dev=ovs-br0
2018-12-17 16:30:53,961 root         DEBUG    Executing NM action: func=_safe_activate_async, args=(None, 'ovs-br0')
2018-12-17 16:30:53,982 root         DEBUG    Connection activation initiated: dev=ovs-br0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATING of type NM.ActiveConnectionState>
2018-12-17 16:30:54,007 root         DEBUG    Connection activation succeeded: dev=ovs-br0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATED of type NM.ActiveConnectionState>
2018-12-17 16:30:54,009 root         DEBUG    NM action queue exhausted, quiting mainloop
2018-12-17 16:30:54,050 root         DEBUG    Connection settings for duplicate_settings:
id: ovs-br0
iface: ovs-br0
uuid: bb00ac99-696f-4fb1-8f53-a8d5daac5710
type: ovs-bridge
autoconnect: False
autoconnect_slaves: <enum NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_NO of type NM.SettingConnectionAutoconnectSlaves>
2018-12-17 16:30:54,055 root         DEBUG    Executing NM action: func=commit_changes_async, args=(True, <Gio.Cancellable object at 0x7f00121c42d0 (GCancellable at 0x7f000c050820)>, <function _commit_changes_callback at 0x7f0012515050>, (<libnmstate.nm.nmclient._MainLoop object at 0x7f0012147c90>, <NM.DeviceOvsBridge object at 0x7f001210fe60 (NMDeviceOvsBridge at 0x55612f6592c0)>))
2018-12-17 16:30:54,063 root         DEBUG    Connection update succeeded: dev=ovs-br0
2018-12-17 16:30:54,064 root         DEBUG    Executing NM action: func=_safe_activate_async, args=(<NM.DeviceOvsBridge object at 0x7f001210fe60 (NMDeviceOvsBridge at 0x55612f6592c0)>, None)
2018-12-17 16:30:54,116 root         DEBUG    Connection activation initiated: dev=ovs-br0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATING of type NM.ActiveConnectionState>
2018-12-17 16:30:54,159 root         DEBUG    Connection activation succeeded: dev=ovs-br0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATED of type NM.ActiveConnectionState>
2018-12-17 16:30:54,160 root         DEBUG    NM action queue exhausted, quiting mainloop
2018-12-17 16:30:54,194 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/4 destroyed
Desired state applied: 
interfaces:
- name: ovs-br0
  type: ovs-bridge
  state: up
  bridge:
    options:
      fail-mode: ''
      mcast-snooping-enable: false
      rstp: false
      stp: true

[dsneddon@localhost nmstate_configs]$ sudo ovs-vsctl show
ee61c88b-46be-4da9-8c83-0b1e4b528270
    ovs_version: "2.10.0"            # <-- No bridge in OVSDB
[dsneddon@localhost nmstate_configs]$


If I try a more complicated bridge with an Ethernet interface attached and an IP on the bridge, I am getting a traceback.

[dsneddon@localhost nmstate_configs]$ cat ovs_bridge_simple.yaml 
interfaces:
- name: ovs-br0
  type: ovs-bridge
  state: up
  bridge:
    options:
      fail-mode: ''
      mcast-snooping-enable: false
      rstp: false
      stp: true


[dsneddon@localhost nmstate_configs]$ cat ovs_bridge.yaml 
interfaces:
- name: enp0s8
  type: ethernet
  state: up
  ipv4:
    enabled: false
- name: ovs-br0
  type: ovs-bridge
  state: up
  bridge:
    options:
      fail-mode: ''
      mcast-snooping-enable: false
      rstp: false
      stp: true
    port:
    - name: enp0s8
      type: system
  ipv4:
    address:
    - ip: 192.0.3.10
      prefix-length: 24
    enabled: true


[dsneddon@localhost nmstate_configs]$ sudo nmstatectl set < ovs_bridge.yaml 
2018-12-17 16:13:55,757 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/1 created for all devices: 60
2018-12-17 16:13:55,758 root         DEBUG    Connection settings for create_setting:
id: ovs-br0
iface: ovs-br0
uuid: 1ed41b89-b7f4-4aaf-89ce-f198f86a2445
type: ovs-bridge
autoconnect: False
autoconnect_slaves: <enum NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_NO of type NM.SettingConnectionAutoconnectSlaves>
2018-12-17 16:13:55,761 root         DEBUG    Executing NM action: func=add_connection_async, args=(<NM.SimpleConnection object at 0x7f3ca03c0dc0 (NMSimpleConnection at 0x55fa22dc9840)>, True, <Gio.Cancellable object at 0x7f3ca04792d0 (GCancellable at 0x7f3c9003ed40)>, <function _add_connection_callback at 0x7f3ca07cbe60>, <libnmstate.nm.nmclient._MainLoop object at 0x7f3ca03f8a90>)
2018-12-17 16:13:55,773 root         DEBUG    Connection adding succeeded: dev=ovs-br0
2018-12-17 16:13:55,773 root         DEBUG    Executing NM action: func=_safe_activate_async, args=(None, 'ovs-br0')
2018-12-17 16:13:55,793 root         DEBUG    Connection activation initiated: dev=ovs-br0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATING of type NM.ActiveConnectionState>
2018-12-17 16:13:55,813 root         DEBUG    Connection activation succeeded: dev=ovs-br0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATED of type NM.ActiveConnectionState>
2018-12-17 16:13:55,813 root         DEBUG    NM action queue exhausted, quiting mainloop
2018-12-17 16:13:55,856 root         DEBUG    Connection settings for duplicate_settings:
id: ovs-br0
iface: ovs-br0
uuid: 1ed41b89-b7f4-4aaf-89ce-f198f86a2445
type: ovs-bridge
autoconnect: False
autoconnect_slaves: <enum NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_NO of type NM.SettingConnectionAutoconnectSlaves>
2018-12-17 16:13:55,857 root         DEBUG    Connection settings for create_setting:
id: enp0s8
iface: enp0s8
uuid: 85f0dd44-cc80-4b16-87fd-f004c6a2354a
type: 802-3-ethernet
autoconnect: False
autoconnect_slaves: <enum NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_NO of type NM.SettingConnectionAutoconnectSlaves>
2018-12-17 16:13:55,861 root         DEBUG    Connection settings for create_setting:
id: ovs-port-enp0s8
iface: ovs-port-enp0s8
uuid: b21ad496-7419-4631-a7d7-7fac0905f052
type: ovs-port
autoconnect: False
autoconnect_slaves: <enum NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_NO of type NM.SettingConnectionAutoconnectSlaves>
2018-12-17 16:13:55,865 root         DEBUG    Executing NM action: func=commit_changes_async, args=(True, <Gio.Cancellable object at 0x7f3ca04792d0 (GCancellable at 0x7f3c9003ed40)>, <function _commit_changes_callback at 0x7f3ca07c6050>, (<libnmstate.nm.nmclient._MainLoop object at 0x7f3ca03f8a90>, <NM.DeviceOvsBridge object at 0x7f3ca03c0e10 (NMDeviceOvsBridge at 0x55fa22e882c0)>))
2018-12-17 16:13:55,891 root         DEBUG    Connection update succeeded: dev=ovs-br0
2018-12-17 16:13:55,891 root         DEBUG    Executing NM action: func=add_connection_async, args=(<NM.SimpleConnection object at 0x7f3ca0479f50 (NMSimpleConnection at 0x55fa22ec8a00)>, True, <Gio.Cancellable object at 0x7f3ca04792d0 (GCancellable at 0x7f3c9003ed40)>, <function _add_connection_callback at 0x7f3ca07cbe60>, <libnmstate.nm.nmclient._MainLoop object at 0x7f3ca03f8a90>)
2018-12-17 16:13:55,906 root         DEBUG    Connection adding succeeded: dev=enp0s8
2018-12-17 16:13:55,907 root         DEBUG    Executing NM action: func=add_connection_async, args=(<NM.SimpleConnection object at 0x7f3ca0479f00 (NMSimpleConnection at 0x55fa22ec88c0)>, True, <Gio.Cancellable object at 0x7f3ca04792d0 (GCancellable at 0x7f3c9003ed40)>, <function _add_connection_callback at 0x7f3ca07cbe60>, <libnmstate.nm.nmclient._MainLoop object at 0x7f3ca03f8a90>)
2018-12-17 16:13:55,922 root         DEBUG    Connection adding succeeded: dev=ovs-port-enp0s8
2018-12-17 16:13:55,922 root         DEBUG    Executing NM action: func=_safe_activate_async, args=(<NM.DeviceOvsBridge object at 0x7f3ca03c0e10 (NMDeviceOvsBridge at 0x55fa22e882c0)>, None)
2018-12-17 16:13:55,969 root         DEBUG    Connection activation initiated: dev=ovs-br0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATING of type NM.ActiveConnectionState>
2018-12-17 16:13:56,006 root         DEBUG    Connection activation succeeded: dev=ovs-br0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATED of type NM.ActiveConnectionState>
2018-12-17 16:13:56,006 root         DEBUG    Executing NM action: func=_safe_activate_async, args=(<NM.DeviceEthernet object at 0x7f3ca03c0f50 (NMDeviceEthernet at 0x55fa22e3a180)>, None)
2018-12-17 16:13:56,046 root         DEBUG    Connection activation initiated: dev=enp0s8, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATING of type NM.ActiveConnectionState>
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/libnmstate/nm/device.py", line 179, in _waitfor_active_connection_callback
    ac.refresh_state()
  File "/usr/lib/python2.7/site-packages/libnmstate/nm/device.py", line 56, in refresh_state
    self._state_reason != nm_acs.DEVICE_DISCONNECTED
AttributeError: type object 'ActiveConnectionState' has no attribute 'DEVICE_DISCONNECTED'
2018-12-17 16:14:15,878 root         WARNING  NM main-loop timed out.
2018-12-17 16:14:15,910 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/1 rollback executed: dbus.Dictionary({dbus.String(u'/org/freedesktop/NetworkManager/Devices/1'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/2'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/3'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/4'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/5'): dbus.UInt32(0L)}, signature=dbus.Signature('su'))
Traceback (most recent call last):
  File "/usr/bin/nmstatectl", line 11, in <module>
    load_entry_point('nmstate==0.0.2', 'console_scripts', 'nmstatectl')()
  File "/usr/lib/python2.7/site-packages/nmstatectl/nmstatectl.py", line 54, in main
    return args.func(args)
  File "/usr/lib/python2.7/site-packages/nmstatectl/nmstatectl.py", line 147, in apply
    netapplier.apply(state, verify_change=args.verify)
  File "/usr/lib/python2.7/site-packages/libnmstate/netapplier.py", line 47, in apply
    _apply_ifaces_state(desired_state[Constants.INTERFACES], verify_change)
  File "/usr/lib/python2.7/site-packages/libnmstate/netapplier.py", line 64, in _apply_ifaces_state
    _edit_interfaces(ifaces_desired_state, ifaces_current_state)
  File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/usr/lib/python2.7/site-packages/libnmstate/netapplier.py", line 97, in _setup_providers
    raise ApplyError(mainloop.error)
libnmstate.netapplier.ApplyError: run timeout
[dsneddon@localhost nmstate_configs]$ nmcli con
NAME                UUID                                  TYPE      DEVICE  
enp0s3              b389bdd3-0f4c-3d32-9d88-dae380b0a280  ethernet  enp0s3  
System enp0s9       93d13955-e9e2-a6bd-df73-12e3c747f122  ethernet  enp0s9  
Wired connection 1  22978086-bea8-3708-a00b-cd7f918ea6d5  ethernet  enp0s10

I also can't bring up an OVS bridge using a legacy init-script, even though I have the init-scripts 

[dsneddon@localhost ~]$ cat /etc/sysconfig/network-scripts/ifcfg-br-ex 
# This file is autogenerated by os-net-config
DEVICE=br-ex
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=yes
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSBridge
OVS_EXTRA="set bridge br-ex fail_mode=standalone -- del-controller br-ex"
[dsneddon@localhost ~]$ sudo ifup br-ex
Error: unknown connection '/etc/sysconfig/network-scripts/ifcfg-br-ex'.

[dsneddon@localhost ~]$ sudo ifup br-ex
Error: unknown connection '/etc/sysconfig/network-scripts/ifcfg-br-ex'.

It appears that it is expected behavior that OVS bridges cannot be brought up via init-scripts: https://bugzilla.redhat.com/show_bug.cgi?id=1589869

I retested with nmstate 0.0.3 and I'm still getting an error trying to create a simple OVS bridge:

[dsneddon@localhost nmstate_configs]$ cat ovs_bridge_simple.yaml 
interfaces:
- name: ovs-br0
  type: ovs-bridge
  state: down
  bridge:
    options:
      fail-mode: ''
      mcast-snooping-enable: false
      rstp: false
      stp: true
[dsneddon@localhost nmstate_configs]$ nmstatectl set < ovs_bridge_simple.yaml
2018-12-18 15:24:38,579 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/6 created for all devices: 60
2018-12-18 15:24:39,166 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/6 rollback executed: dbus.Dictionary({dbus.String(u'/org/freedesktop/NetworkManager/Devices/1'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/2'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/3'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/4'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/5'): dbus.UInt32(0L), dbus.String(u'/org/freedesktop/NetworkManager/Devices/6'): dbus.UInt32(0L)}, signature=dbus.Signature('su'))
Traceback (most recent call last):
  File "/home/dsneddon/.local/bin/nmstatectl", line 11, in <module>
    load_entry_point('nmstate==0.0.3', 'console_scripts', 'nmstatectl')()
  File "/home/dsneddon/.local/lib/python2.7/site-packages/nmstatectl/nmstatectl.py", line 54, in main
    return args.func(args)
  File "/home/dsneddon/.local/lib/python2.7/site-packages/nmstatectl/nmstatectl.py", line 147, in apply
    netapplier.apply(state, verify_change=args.verify)
  File "/home/dsneddon/.local/lib/python2.7/site-packages/libnmstate/netapplier.py", line 47, in apply
    _apply_ifaces_state(desired_state[Constants.INTERFACES], verify_change)
  File "/home/dsneddon/.local/lib/python2.7/site-packages/libnmstate/netapplier.py", line 66, in _apply_ifaces_state
    _verify_change(ifaces_desired_state)
  File "/home/dsneddon/.local/lib/python2.7/site-packages/libnmstate/netapplier.py", line 77, in _verify_change
    assert_ifaces_state(ifaces_desired_state, ifaces_current_state)
  File "/home/dsneddon/.local/lib/python2.7/site-packages/libnmstate/netapplier.py", line 316, in assert_ifaces_state
    ifaces_current_state)
libnmstate.netapplier.DesiredStateIsNotCurrentError: 
desired
=======
ovs-br0:
  bridge:
    options:
      fail-mode: ''
      mcast-snooping-enable: false
      rstp: false
      stp: true
  name: ovs-br0
  state: down
  type: ovs-bridge

current
=======
enp0s10:
  ipv4:
    enabled: false
  ipv6:
    enabled: false
  mtu: 1500
  name: enp0s10
  state: down
  type: ethernet
enp0s3:
  ethernet:
    auto-negotiation: true
    duplex: full
    speed: 1000
  ipv4:
    address:
    - ip: 192.168.53.148
      prefix-length: 24
    enabled: true
  ipv6:
    address:
    - ip: fe80::81fd:5031:a938:28b7
      prefix-length: 64
    enabled: true
  mtu: 1500
  name: enp0s3
  state: up
  type: ethernet
enp0s8:
  ipv4:
    enabled: false
  ipv6:
    enabled: false
  mtu: 1500
  name: enp0s8
  state: down
  type: ethernet
enp0s9:
  ipv4:
    address:
    - ip: 192.168.120.10
      prefix-length: 24
    enabled: true
  ipv6:
    address:
    - ip: fe80::a00:27ff:fef4:d514
      prefix-length: 64
    enabled: true
  mtu: 1500
  name: enp0s9
  state: up
  type: ethernet
lo:
  ipv4:
    enabled: false
  ipv6:
    enabled: false
  mtu: 65536
  name: lo
  state: down
  type: unknown
vlan100:
  ipv4:
    enabled: false
  ipv6:
    enabled: false
  mtu: 1500
  name: vlan100
  state: down
  type: vlan
  vlan:
    base-iface: enp0s8
    id: 100

difference
==========
--- desired
+++ current
@@ -1,10 +1,73 @@
-ovs-br0:
-  bridge:
-    options:
-      fail-mode: ''
-      mcast-snooping-enable: false
-      rstp: false
-      stp: true
-  name: ovs-br0
+enp0s10:
+  ipv4:
+    enabled: false
+  ipv6:
+    enabled: false
+  mtu: 1500
+  name: enp0s10
   state: down
-  type: ovs-bridge
+  type: ethernet
+enp0s3:
+  ethernet:
+    auto-negotiation: true
+    duplex: full
+    speed: 1000
+  ipv4:
+    address:
+    - ip: 192.168.53.148
+      prefix-length: 24
+    enabled: true
+  ipv6:
+    address:
+    - ip: fe80::81fd:5031:a938:28b7
+      prefix-length: 64
+    enabled: true
+  mtu: 1500
+  name: enp0s3
+  state: up
+  type: ethernet
+enp0s8:
+  ipv4:
+    enabled: false
+  ipv6:
+    enabled: false
+  mtu: 1500
+  name: enp0s8
+  state: down
+  type: ethernet
+enp0s9:
+  ipv4:
+    address:
+    - ip: 192.168.120.10
+      prefix-length: 24
+    enabled: true
+  ipv6:
+    address:
+    - ip: fe80::a00:27ff:fef4:d514
+      prefix-length: 64
+    enabled: true
+  mtu: 1500
+  name: enp0s9
+  state: up
+  type: ethernet
+lo:
+  ipv4:
+    enabled: false
+  ipv6:
+    enabled: false
+  mtu: 65536
+  name: lo
+  state: down
+  type: unknown
+vlan100:
+  ipv4:
+    enabled: false
+  ipv6:
+    enabled: false
+  mtu: 1500
+  name: vlan100
+  state: down
+  type: vlan
+  vlan:
+    base-iface: enp0s8
+    id: 100

These PRs fix at least some of the issues that you saw (I saw them as well when trying to test this locally as well):
https://github.com/nmstate/nmstate/pull/200
https://github.com/nmstate/nmstate/pull/201

Some observations that I made:
- NetworkManager needs to be restarted after installing NetworkManager-ovs
- ovs-vsctl show failed when I did not run: systemctl start openvswitch
- After I started openvswitch, I needed to restart NetworkManager to get ovs-vsctl show the bridges that NetworkManager (should have) created. They already appeared in nmcli con in green
- Getting an IP assigned in a way that it was displayed in nmstatectl failed for me, too

Thanks Till, I made some progress and managed to create OVS bridges, but was unable to assign an IP.

Dan, adding an IP to a OVS bridge is not supported at the moment. It needs some extra code to add another kind of interface to NM that needs to be written in nmstate.

Dan, setting the IP is now supported with an extra ovs-interface as shown here: https://github.com/nmstate/nmstate/blob/master/examples/ovsbridge_create.yml - does this work for you?

(In reply to Till Maas from comment #9)
> Dan, setting the IP is now supported with an extra ovs-interface as shown
> here:
> https://github.com/nmstate/nmstate/blob/master/examples/ovsbridge_create.yml
> - does this work for you?

I'll test this. What we need is to be able to duplicate the behavior of the network service/init-scripts, which duplicated the behavior of ovs-vsctl, where a bridge would automatically be created with an internal interface with the same name as the bridge.

For example:

[dsneddon@localhost os-net-config]$ sudo ovs-vsctl add-br br-test
[dsneddon@localhost os-net-config]$ sudo ovs-vsctl show
ee61c88b-46be-4da9-8c83-0b1e4b528270
    Bridge br-test
        Port br-test
            Interface br-test
                type: internal
    Bridge test
        Port test
            Interface test
                type: internal
    ovs_version: "2.10.0"

So as long as I can create an internal interface with the same name as the bridge, this will work great. Thanks!

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Reopening as this is still a problem. The last request to be able to properly simulate the network-scripts behavior is still needed.

For reference the network-scripts would look something like...

loop1 was created with:
ip link add name loop1 type dummy && ip addr add 127.2.0.1/24 dev loop1


[stack@multi-3 ~]$ cat /etc/sysconfig/network-scripts/ifcfg-loop1
DEVICE=loop1
NAME=loop1
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=br-ex
ONBOOT=yes
BOOTPROTO=none
[stack@multi-3 ~]$ cat /etc/sysconfig/network-scripts/ifcfg-br-ex
ONBOOT=yes
PEERDNS=no
NM_CONTROLLED=no
NOZEROCONF=yes
DEVICE=br-ex
NAME=br-ex
DEVICETYPE=ovs
OVSBOOTPROTO=dhcp
TYPE=OVSBridge
OVS_EXTRA="set bridge br-ex fail_mode=standalone"

The result vsctl configuration would be:

[stack@multi-3 ~]$ sudo ovs-vsctl show
31259845-3078-449c-bc6f-b2294168862b
    Bridge br-ex
        fail_mode: standalone
        Port br-ex
            Interface br-ex
                type: internal
        Port loop1
            Interface loop1
    ovs_version: "2.15.1"

For the record ovs-vsctl add-br <name> automatically creates the interface of the same name. There doesn't appear to be a way to do that via nmcli or nmstate. currently we're trying to replace our ifcfg vs_port config which 


[stack@multi-3 ~]$ sudo ovs-vsctl add-br foobar
[stack@multi-3 ~]$ sudo ovs-vsctl show
849dd216-451f-40e6-b489-77c6c8101e28
    Bridge foobar
        Port foobar
            Interface foobar
                type: internal
    ovs_version: "2.15.1"

What we end up configuring are ports and additional options on the interface after the fact. ovs appears to manage the lifecycle of the bridge/interface.  I wonder if there's a better way to handle this with nmstate/nm

Actually you can do it via nmcli, though it is not a fan of the name re-usage (but it works fine). 

[stack@multi-0 ~]$ sudo nmcli c add type ovs-bridge conn.interface foobar con-name foobar 
Connection 'foobar' (b3a19299-6b10-4cbb-921f-a5265c8289d5) successfully added.
[stack@multi-0 ~]$ sudo nmcli c add type ovs-port conn.interface foobar master foobar con-name foobar
Warning: There is another connection with the name 'foobar'. Reference the connection by its uuid '5f03b02e-cd5f-4147-9ecf-8ec75ce456df'
Connection 'foobar' (5f03b02e-cd5f-4147-9ecf-8ec75ce456df) successfully added.
[stack@multi-0 ~]$ sudo nmcli c add type ovs-interface slave-type ovs-port conn.interface foobar master foobar con-name foobar
Warning: There are 2 other connections with the name 'foobar'. Reference the connection by its uuid '59a5fe01-5eed-40e9-9df9-a177b031e5d7'
Connection 'foobar' (59a5fe01-5eed-40e9-9df9-a177b031e5d7) successfully added.
[stack@multi-0 ~]$ sudo ovs-vsctl show
81aa23f3-3042-4886-a541-49a3fd407d6e
    Bridge foobar
        Port foobar
            Interface foobar
                type: internal
    ovs_version: "2.15.1"

Additionally `sudo nmcli c delete foobar` cleans up all 3 items at once (which is nice)

[stack@multi-0 ~]$ sudo nmcli c delete foobar
Connection 'foobar' (b3a19299-6b10-4cbb-921f-a5265c8289d5) successfully deleted.
Connection 'foobar' (5f03b02e-cd5f-4147-9ecf-8ec75ce456df) successfully deleted.
Connection 'foobar' (59a5fe01-5eed-40e9-9df9-a177b031e5d7) successfully deleted.

Created attachment 1801611 [details]
ovs.yaml

The actions don't appear to be compatible with nmstate apply. After creating the interfaces via nmcli, I dumped the state using `nmstate show > ovs.yaml`.  Then I removed the interface, bridge, port via nmcli and attempted to reapply via nmstate and it fails.

See attached ovs.yaml and apply.log

Created attachment 1801612 [details]
apply.log

[stack@multi-0 ~]$ rpm -qa | egrep "(nmstate|NetworkManager)"
NetworkManager-libnm-1.32.2-1.el9.x86_64
NetworkManager-1.32.2-1.el9.x86_64
NetworkManager-ovs-1.32.2-1.el9.x86_64
NetworkManager-team-1.32.2-1.el9.x86_64
NetworkManager-config-server-1.32.2-1.el9.noarch
nmstate-plugin-ovsdb-2.0.0-0.1.alpha1.el9.noarch
python3-libnmstate-2.0.0-0.1.alpha1.el9.noarch
nmstate-2.0.0-0.1.alpha1.el9.noarch
NetworkManager-tui-1.32.2-1.el9.x86_64

Hello! I am looking into this. I didn't reproduce this with the current base. I tried this using nmstate-2.0.0-0.3.alpha2.el9, I will try with the alpha1 and find the patch that is fixing the problem if possible.

Thank you!
Fernando.

It did not work for me this morning with alpha2.

[stack@multi-0 ~]$ rpm -qa | grep nmstate
nmstate-plugin-ovsdb-2.0.0-0.2.alpha2.el9.noarch
python3-libnmstate-2.0.0-0.2.alpha2.el9.noarch
nmstate-2.0.0-0.2.alpha2.el9.noarch

I used:

nmcli conn add type ovs-bridge conn.interface br-test con-name br-test 
nmcli conn add type ovs-port conn.interface br-test master br-test con-name ovs-port-br-test
nmcli conn add type ovs-interface slave-type ovs-port conn.interface br-test master ovs-port-br-test con-name ovs-if-br-test 
nmcli conn add type ovs-port conn.interface ens4 master br-test con-name ovs-port-ens4
nmcli c add type ethernet conn.interface ens4 master ovs-port-ens4 con-name ovs-if-ens4 
sleep 2

nmcli c
ip a

nmstatectl show > ovs.yaml

nmcli c del ovs-if-ens4
nmcli c del ovs-port-ens4
nmcli c del ovs-if-br-test
nmcli c del ovs-port-br-test
nmcli c del br-test
sleep 2

nmcli c
ip a

nmstatectl apply < ovs.yaml

nmcli c
ip a

Created attachment 1813463 [details]
nmstate.log

Hi Alex, can you please try the ovs.yaml after you removed the information about the connection UUID:

ovs-db:
  external_ids:
    NM.connection.uuid: 69ace8bf-0011-4a9f-a848-7d3ef86c7ec0

Yup that works. Anyway to get that filtered out on output or maybe ignored on apply?

Actually it's changing the connection names on apply which is problematic because nmcli doesn't exactly like duplicate connection names.

NAME              UUID                                  TYPE           DEVICE  
ovs-if-br-test    125bcc00-56c2-4384-823b-3127c927305a  ovs-interface  br-test 
System ens3       21d47e65-8523-1a06-af22-6f121086f085  ethernet       ens3    
br-test           c022cce7-71bc-4e76-b3fc-b3202949275c  ovs-bridge     br-test 
ovs-if-ens4       1e6f37e7-d2f7-4d06-a7f1-0e5754f73499  ethernet       ens4    
ovs-port-br-test  627bd188-14be-427a-bf53-2bacb24bc171  ovs-port       br-test 
ovs-port-ens4     18e27f61-f16c-4961-8c50-8f877bc1f0a5  ovs-port       ens4    
enp1s0            2f5648d1-0a78-4bba-9b96-7f9e09d38b8c  ethernet       --      


After apply turns into

NAME              UUID                                  TYPE           DEVICE           
ens3              21d47e65-8523-1a06-af22-6f121086f085  ethernet       ens3             
br-test           e86501ca-d16d-4276-81f3-3d4b0a5bca22  ovs-interface  br-test          
br-test           addad816-5b18-4135-9b76-f10e7dd120bc  ovs-bridge     br-test          
ens4              827a6deb-3d64-4182-be00-538abd34fbaf  ethernet       ens4             
ovs-port-br-test  5cb364d6-a530-44be-8b5e-0d1f33ab3d46  ovs-port       ovs-port-br-test 
ovs-port-ens4     cd59e5ca-4173-4e7f-b848-bd329ee92cd5  ovs-port       ovs-port-ens4    
enp1s0            2f5648d1-0a78-4bba-9b96-7f9e09d38b8c  ethernet       --   


br-test is duplicated

And the 'Ssystem ens3' is renamed to 'ens3'

(In reply to Alex Schultz from comment #28)
> Actually it's changing the connection names on apply which is problematic
> because nmcli doesn't exactly like duplicate connection names.

That is expected. Nmstate is interface based and not profile based. That means when the user specify a configuration for a specific interface, Nmstate will delete/modify the existing connection and create it's own one. The connection name will be the interface name. It is true that nmcli requires the user to use the UUID instead the connection name when they are duplicated but is there a requirement that is forcing you to use nmcli and nmstate?

Why would it be a problem?

Thank you!

> 
> NAME              UUID                                  TYPE          
> DEVICE  
> ovs-if-br-test    125bcc00-56c2-4384-823b-3127c927305a  ovs-interface 
> br-test 
> System ens3       21d47e65-8523-1a06-af22-6f121086f085  ethernet       ens3 
> 
> br-test           c022cce7-71bc-4e76-b3fc-b3202949275c  ovs-bridge    
> br-test 
> ovs-if-ens4       1e6f37e7-d2f7-4d06-a7f1-0e5754f73499  ethernet       ens4 
> 
> ovs-port-br-test  627bd188-14be-427a-bf53-2bacb24bc171  ovs-port      
> br-test 
> ovs-port-ens4     18e27f61-f16c-4961-8c50-8f877bc1f0a5  ovs-port       ens4 
> 
> enp1s0            2f5648d1-0a78-4bba-9b96-7f9e09d38b8c  ethernet       --   
> 
> 
> 
> After apply turns into
> 
> NAME              UUID                                  TYPE          
> DEVICE           
> ens3              21d47e65-8523-1a06-af22-6f121086f085  ethernet       ens3 
> 
> br-test           e86501ca-d16d-4276-81f3-3d4b0a5bca22  ovs-interface 
> br-test          
> br-test           addad816-5b18-4135-9b76-f10e7dd120bc  ovs-bridge    
> br-test          
> ens4              827a6deb-3d64-4182-be00-538abd34fbaf  ethernet       ens4 
> 
> ovs-port-br-test  5cb364d6-a530-44be-8b5e-0d1f33ab3d46  ovs-port      
> ovs-port-br-test 
> ovs-port-ens4     cd59e5ca-4173-4e7f-b848-bd329ee92cd5  ovs-port      
> ovs-port-ens4    
> enp1s0            2f5648d1-0a78-4bba-9b96-7f9e09d38b8c  ethernet       --   
> 
> 
> br-test is duplicated

(In reply to Alex Schultz from comment #27)
> Yup that works. Anyway to get that filtered out on output or maybe ignored
> on apply?

No, there is no such an option. The failure that you are getting is considered a bug as Nmstate should be able to apply the configuration provided. Removing it from the desired state is only a temporarily workaround.

Thanks!

(In reply to Fernando F. Mancera from comment #30)
> (In reply to Alex Schultz from comment #28)
> > Actually it's changing the connection names on apply which is problematic
> > because nmcli doesn't exactly like duplicate connection names.
> 
> That is expected. Nmstate is interface based and not profile based. That
> means when the user specify a configuration for a specific interface,
> Nmstate will delete/modify the existing connection and create it's own one.
> The connection name will be the interface name. It is true that nmcli
> requires the user to use the UUID instead the connection name when they are
> duplicated but is there a requirement that is forcing you to use nmcli and
> nmstate?
> 
> Why would it be a problem?
> 

Yea if names change and an external tool is leveraging the names for configuration it can lead to idempotency issues.  We shouldn't change names or duplicate them.  Naming should be consistent and accounted for

Hi Alex,

I assume the remaining issue for this bug is nmstate should not change existing connection name.
Is there other issues from your side for this bug?

At last testing  my understanding of the outstanding issues would be:

1) NM.connection.uuid causing the connections to not be created
2) connection name duplication
3) renaming of existing connections

(In reply to Alex Schultz from comment #34)
> At last testing  my understanding of the outstanding issues would be:
> 
> 1) NM.connection.uuid causing the connections to not be created
> 2) connection name duplication
> 3) renaming of existing connections

Hi Alex,

We are going to use this bug report for the NM.Connection.uuid issue which is a bug. For the other two issues, could you create two different reports? We want to track the issues properly.

Thank you!

Created new bugs for the other issues. I can verify that alpha2 does address the NM.connection.uuid thing as I didn't have to remove it when reproducing the issues for the new bugs.

(In reply to Alex Schultz from comment #36)
> Created new bugs for the other issues. I can verify that alpha2 does address
> the NM.connection.uuid thing as I didn't have to remove it when reproducing
> the issues for the new bugs.

That is strange. I am able to reproduce it using base branch and alpha2 version. I am working on it.

difference
==========
--- desired
+++ current
@@ -51,4 +51,4 @@
 mtu: 1500
 ovs-db:
   external_ids:
-    NM.connection.uuid: 930aa309-99b1-4fe9-a300-ceec3efd9907
+    NM.connection.uuid: 2fe14d2b-3465-43bb-8a49-f65ded332238

This issue is being fixed by: https://github.com/nmstate/nmstate/pull/1697

upstream PR had a comment:
"But wondering why openstack need to alter the NM.connection.uuid which is supposed by maintained by NetworkManager only."

Not sure if that was clarified, @Dan can you answer that?

> Status: POST → MODIFIED

For MODIFIED we should have a build in Brew/Koji and I don't see this included in https://gitlab.com/redhat/centos-stream/rpms/nmstate/-/commits/c9s

Last content change was Upgrade to 2.0.0 alpha2 in July, which pre-release should include this fix?

(In reply to Alan Pevec from comment #39)
> upstream PR had a comment:
> "But wondering why openstack need to alter the NM.connection.uuid which is
> supposed by maintained by NetworkManager only."
> 
> Not sure if that was clarified, @Dan can you answer that?

That comment is due to a different fix I was suggesting. Openstack does not need to alter the NM.connection.uuid and indeed, we should not expose it. This is why we removed that entry.

Tested on nmstate with commit up to 0467c4f47e2eeef12b7b325344a45d77edd8fd82.
The nmstate is not showing `NM.connection.uuid` any more.

Verified with versions:
nmstate-2.0.0-0.4.alpha3.el9.noarch
nispor-1.1.1-2.el9.x86_64
NetworkManager-1.32.10-2.el9.x86_64

NM.connection.uuid doesn't show, need more checking on the existing test

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 (new packages: nmstate), 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/RHEA-2022:2338