#1149299 netplan.io: autopkgtest "ovs" test_ovsdb_server_is_not_running fails with openvswitch 4.0 (ovsdb-server.socket)

Package:
src:netplan.io
Source:
src:netplan.io
Submitter:
Sebastien Bacher
Date:
2026-09-29 08:59:02 UTC
Severity:
normal
Tags:
#1149299#5
Date:
2026-09-29 08:56:14 UTC
From:
To:
Dear Maintainer,

openvswitch 4.0.0 (now in sid/forky) ships ovsdb-server.socket, so
ovsdb-server is started on demand (socket activation). netplan.io's
integration test test_ovsdb_server_is_not_running
(tests/integration/ovs.py) only stops ovsdb-server.service. Netplan's
"ovs-vsctl show" check then connects to the socket, systemd starts
ovsdb-server again, and the expected error is never raised:

  Stopping 'ovsdb-server.service', but its triggering units are still
active:
  ovsdb-server.socket
  FAIL: test_ovsdb_server_is_not_running
(__main__.TestOVS.test_ovsdb_server_is_not_running)
  AssertionError: 'OpenvSwitch database is not running' not found in ''

This fails in every Ubuntu autopkgtest run that has openvswitch 4.0.0,
and blocks openvswitch migration there:
https://autopkgtest.ubuntu.com/packages/n/netplan.io/stonking/amd64

On debci the failure doesn't show, because openvswitch-switch.service
is inactive in the testbed, so the "ovs" test exits 77 and is skipped
(e.g. unstable/arm64, 2026-09-26):

  test ovs: (systemctl is-active openvswitch-switch.service || exit 77) &&
...
  inactive
  ovs                  SKIP exit status 77 and marked as skippable

So the test is broken in Debian too, but the CI doesn't show it.

Upstream has fixed the test (not in a release yet, latest is 1.2.2):

  commit 14780cf6b2277ceb066a3cdbfee5523de8c3d1d4
  "tests/integration: fix ovsdb-server test on OVS 4.0.0+ (#613)"

https://github.com/canonical/netplan/commit/14780cf6b2277ceb066a3cdbfee5523de8c3d1d4

The fix also stops ovsdb-server.socket in the test and restarts it
during cleanup. It still works with older OVS releases that don't have
the unit. Please consider adding it to debian/patches.

Side note: with OVS >= 4.0, "netplan apply" starts the DB again through
the socket instead of reporting "OpenvSwitch database is not running"
when an admin has stopped only ovsdb-server.service. That seems fine,
but it's a behaviour change.