Activity log for bug #1943120

Date Who What changed Old value New value Message
2021-09-09 09:42:36 Michael Vogt bug added bug
2021-09-09 09:42:36 Michael Vogt attachment added Reproducer shell script https://bugs.launchpad.net/bugs/1943120/+attachment/5523969/+files/netplan-dbus-perculiar.sh
2021-09-24 08:12:08 Lukas Märdian netplan: status New Triaged
2021-09-24 08:12:30 Lukas Märdian tags fr-1745
2021-09-24 10:28:11 Lukas Märdian bug watch added https://github.com/systemd/systemd/issues/6600
2021-09-24 10:28:42 Lukas Märdian bug task added systemd
2021-09-24 11:34:50 Bug Watch Updater systemd: status Unknown New
2021-09-27 14:48:49 Lukas Märdian bug task added netplan.io (Ubuntu)
2021-09-27 14:48:58 Lukas Märdian netplan: status Triaged Fix Committed
2021-09-27 14:49:04 Lukas Märdian nominated for series Ubuntu Hirsute
2021-09-27 14:49:04 Lukas Märdian bug task added netplan.io (Ubuntu Hirsute)
2021-09-27 14:49:04 Lukas Märdian nominated for series Ubuntu Focal
2021-09-27 14:49:04 Lukas Märdian bug task added netplan.io (Ubuntu Focal)
2021-09-27 14:49:04 Lukas Märdian nominated for series Ubuntu Impish
2021-09-27 14:49:04 Lukas Märdian bug task added netplan.io (Ubuntu Impish)
2021-09-29 15:01:52 Launchpad Janitor netplan.io (Ubuntu Impish): status New Fix Released
2021-10-06 12:46:45 Simon Chopin description 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. [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 # cp -r /etc/netplan /etc/netplan_backup # netplan set network.bridges.br54=null # netplan get # check that br54 is NOT present # netplan apply --state /etc/netplan_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.
2021-10-06 13:45:58 Simon Chopin 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 # cp -r /etc/netplan /etc/netplan_backup # netplan set network.bridges.br54=null # netplan get # check that br54 is NOT present # netplan apply --state /etc/netplan_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. [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.
2021-10-06 13:46:07 Simon Chopin netplan.io (Ubuntu Focal): status New In Progress
2021-10-06 13:46:10 Simon Chopin netplan.io (Ubuntu Focal): assignee Simon Chopin (schopin)
2021-10-06 13:46:12 Simon Chopin netplan.io (Ubuntu Hirsute): assignee Simon Chopin (schopin)
2021-10-06 13:46:14 Simon Chopin netplan.io (Ubuntu Hirsute): status New In Progress
2021-10-06 16:59:54 Launchpad Janitor merge proposal linked https://code.launchpad.net/~schopin/netplan/+git/ubuntu/+merge/409760
2021-10-06 17:10:21 Launchpad Janitor merge proposal linked https://code.launchpad.net/~schopin/netplan/+git/ubuntu/+merge/409761
2021-10-06 17:11:13 Launchpad Janitor merge proposal linked https://code.launchpad.net/~schopin/netplan/+git/ubuntu/+merge/409762
2021-10-11 22:24:58 Brian Murray netplan.io (Ubuntu Hirsute): status In Progress Fix Committed
2021-10-11 22:25:00 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2021-10-11 22:25:02 Brian Murray bug added subscriber SRU Verification
2021-10-11 22:25:06 Brian Murray tags fr-1745 fr-1745 verification-needed verification-needed-hirsute
2021-10-11 22:26:26 Brian Murray netplan.io (Ubuntu Focal): status In Progress Fix Committed
2021-10-11 22:26:32 Brian Murray tags fr-1745 verification-needed verification-needed-hirsute fr-1745 verification-needed verification-needed-focal verification-needed-hirsute
2021-10-22 13:07:21 Lukas Märdian tags fr-1745 verification-needed verification-needed-focal verification-needed-hirsute fr-1745 verification-done-hirsute verification-needed verification-needed-focal
2021-10-22 13:20:32 Lukas Märdian tags fr-1745 verification-done-hirsute verification-needed verification-needed-focal fr-1745 verification-done-focal verification-done-hirsute verification-needed
2021-10-25 17:34:32 Launchpad Janitor netplan.io (Ubuntu Hirsute): status Fix Committed Fix Released
2021-10-25 17:34:42 Brian Murray removed subscriber Ubuntu Stable Release Updates Team
2021-10-25 17:35:00 Launchpad Janitor netplan.io (Ubuntu Focal): status Fix Committed Fix Released
2021-11-05 16:58:52 Lukas Märdian netplan: status Fix Committed Fix Released