Skip to content

[th/rh2152864-ovs-autoactivate] device: trigger a recheck to autoconnect when unrealizing ovs-interface

Thomas Haller requested to merge th/rh2152864-ovs-autoactivate into main

NM_reboot_openvswitch_vlan_configuration_var2 test exposes a race. What the test does, is to create OVS profiles and repeatedly restart NetworkManager, checking that those profiles autoconnect and the OVS configuration gets created.

There is a race, where:

  • the OVS interface exists, and an NMDeviceOvsInterface is created
  • first ovsdb cleans up old interfaces, sending a json request.
  • OVS deletes the interface, and NetworkManager first picks up the platform signal (there is a race here, usually the ovsdb request completes first, which will cleanup the NMDeviceOvsInterface in a different way).
  • when the device gets unrealized, we don't schedule a check-autoactivate, so the device stays down.

See https://bugzilla.redhat.com/show_bug.cgi?id=2152864#c5 for a log file with more details.

What should instead happen, is to autoactivate the OVS interface, which then also fully configures the port and bridge interfaces.

Explicitly schedule an autoactivate when unrealizing devices. While the issue is here seen with OVS interfaces, it should always be safe to schedule a autoactivate check (albeit useless). Also not that some common cases where the device gets deactivated, the autoconnect check also gets scheduled.

https://bugzilla.redhat.com/show_bug.cgi?id=2152864

Fixes-test: @NM_reboot_openvswitch_vlan_configuration_var2

NetworkManager-ci!1404 (merged)

Edited by Thomas Haller

Merge request reports