[Bug 1943120] Re: interface not removed

Lukas Märdian 1943120 at bugs.launchpad.net
Fri Nov 5 16:58:52 UTC 2021


** Changed in: netplan
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to netplan.io in Ubuntu.
Matching subscriptions: foundations-bugs
https://bugs.launchpad.net/bugs/1943120

Title:
  interface not  removed

Status in netplan:
  Fix Released
Status in systemd:
  New
Status in netplan.io package in Ubuntu:
  Fix Released
Status in netplan.io source package in Focal:
  Fix Released
Status in netplan.io source package in Hirsute:
  Fix Released
Status in netplan.io source package in Impish:
  Fix Released

Bug description:
  [Impact]

  Virtual devices such as bridge interfaces that are created via netplan
  aren't destroyed when they are removed from the active netplan
  configuration.

  This is a known issue and has been the case for a long time:
  http://manpages.ubuntu.com/manpages/focal/man8/netplan-apply.8.html#known%20issues

  It is problematic as it can break network connectivity when doing
  `netplan apply` even though the netplan configuration itself might be
  correct, leading the user to search for an issue that isn't there.

  This patch only brings a workaround, by allowing the user to manually
  provide the previous configuration, which netplan will use to see what
  the diff is.

  [Test Plan]

  On a VM, assuming no bridge interface is configured:

  # netplan set network.bridges.br54.dhcp4=false
  # netplan get # check that br54 is present
  # netplan apply
  # ip link show br54 && echo OK
  # mkdir -p /tmp/np_backup/etc/ && cp -r /etc/netplan /tmp/np_backup/etc/
  # netplan set network.bridges.br54=null
  # netplan get # check that br54 is NOT present
  # netplan apply --state /tmp/np_backup
  # ip link show br54 && echo ERROR

  [Potential Problems]

  As usual, any netplan upgrade has the potential of breaking the user's
  network setup.

  This patch could make things worse: it's conceivable that with these
  changes, `netplan apply --state backup` could result in a working system
  but the configuration applied at startup wouldn't be correct. Indeed,
  the delta between the `apply` codepath and what is run at startup grows
  larger with this change.

  [Original report]

  While working on the UC20 integration for netplan I ran into the follow,
  I may misunderstand how netplan dbus works so feel free to close as
  "Invalid" if it's my misconception (and apologizes in this case). Any
  help appreciated.

  I ran into this while writing integration tests for snapd netplan
  integration, I create (via the dbus api) a bridge br54, set it to dhcp
  and then unset the interface again. After unset the br54 interface is
  still available but AIUI it should be deleted. Attached is a reproducer
  that uses the same dbus api as snapd is using. I ran it on a fresh 21.04
  VM and got the same issue so it's probably not UC20 specific.

  If I do similar things using "netplan set/netplan try/netplan appy"
  directly it seems that the interface gets deleted as expected. I did not
  write a script for this though, just manually tried it so I might be
  wrong here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1943120/+subscriptions




More information about the foundations-bugs mailing list