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 |
|