[Bug 1997467] Re: Update 0.105-0ubuntu2~22.04.1 seems to cause regressions with snapd integration
Łukasz Zemczak
1997467 at bugs.launchpad.net
Mon Feb 13 11:54:40 UTC 2023
** Changed in: netplan.io (Ubuntu Jammy)
Milestone: None => ubuntu-22.04.2
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1997467
Title:
Update 0.105-0ubuntu2~22.04.1 seems to cause regressions with snapd
integration
Status in netplan:
Fix Committed
Status in netplan.io package in Ubuntu:
Fix Released
Status in netplan.io source package in Jammy:
Confirmed
Status in netplan.io source package in Kinetic:
Confirmed
Status in netplan.io source package in Lunar:
Fix Released
Bug description:
[Impact]
This release contains an important bug-fix, related to the "netplan set" subcommand,
and we would like to make sure all of our supported customers have access to this improvement.
The notable changes in the package are:
* d/p/lp1997467: set only specific origin-hint if given (LP: #1997467)
* d/libnetplan0.symbols: Add netplan_parser_load_nullable_overrides() API
The issues addressed by this SRU are described below.
Some regressions were introduced on netplan.io 0.105 in the subcommand "netplan set".
Users who rely on "netplan set" as part of their workflows, such as snapd, were affected
by these issues. Snapd in particular was forced to rollback to netplan.io 0.104 to unblock
their customers.
Issue 1) Deletion of the origin-hint file on update
netplan set --origin-hint test "bridges.br54.dhcp4=false"
The command above will create the file /etc/netplan/test.yaml
The command below should update the file, but it will be deleted instead
netplan set --origin-hint test "bridges.br54.dhcp4=true"
Issue 2) Updates being ignored when --origin-hint is used
Updates on interfaces already defined in another file are ignored.
The command below should create a new file (in this case called 90-snapd-config.yaml)
containing the definition specified by its last parameter:
netplan set --origin-hint 90-snapd-config bridges.br54.dhcp4=false
Although, if the interface br54 is already defined in another file, netplan set will not
create the file 90-snapd-config.yaml.
[Test Plan]
The following development and SRU process was followed:
https://wiki.ubuntu.com/NetplanUpdates
Netplan contains an extensive integration test suite that is ran using
the SRU package for each releases. This test suite's results are available here:
http://autopkgtest.ubuntu.com/packages/n/netplan.io
* Steps to reproduce the issue
This bug is easily reproducible on netplan.io 0.105-0ubuntu2, which is
used by Kinetic and Jammy.
1) Launch a LXD Jammy instance (either VM or container):
lxc launch ubuntu:22.04 jammy-netplan
2) Access the new instance
lxc exec jammy-netplan bash
3) (Optional) Upgrade your packages
apt update && apt -y upgrade
4) Check the netplan.io version you have
dpkg --list | grep netplan.io
You should see "0.105-0ubuntu2", the version with this bug.
5) Create the file /etc/netplan/0-snapd-defaults.yaml
cat <<EOF > /etc/netplan/0-snapd-defaults.yaml
network:
version: 2
ethernets:
ens3:
addresses:
- "10.0.2.15/24"
dhcp4: false
routes:
- to: "default"
via: "10.0.2.2"
bridges:
br54:
dhcp4: true
EOF
6) Use "netplan set" to create a new file that will be used to change
the bridge configuration defined in the previous file
netplan set --origin-hint 90-snapd-config
network.bridges.br54.dhcp4=false
7) Checking the results
After running "netplan set" you should find a new file at /etc/netplan called 90-snapd-config.yaml
containing only the snippet "network.bridges.br54.dhcp4=false" set with netplan set. It looks like this:
# cat /etc/netplan/90-snapd-config.yaml
network:
version: 2
bridges:
br54:
dhcp4: false
If you are running the netplan.io version affected by this issue, you will not find the new file.
That is the main problem this SRU addresses.
8) Now add the PPA below which contains a netplan.io package with
patches for this issue
sudo add-apt-repository ppa:danilogondolfo/netplan.io
apt update
apt upgrade
9) Try netplan set again
netplan set --origin-hint 90-snapd-config
network.bridges.br54.dhcp4=false
After running "netplan set" the file /etc/netplan/90-snapd-config.yaml
will be generated.
A successful run is required before the proposed netplan package
can be let into -updates.
The netplan team will be in charge of attaching the artifacts and console
output of the appropriate run to the bug. Netplan team members will not
mark ‘verification-done’ until this has happened.
[Where problems could occur]
As this patch changes a small portion of code used by the netplan generator (and the "netplan generate" command),
an issue introduced by this change would potentially affect the network configuration generated when the system boots up.
In the worst scenario it would end up removing old configuration and not generating new one or missing some parts of it
preventing the system to have a working network connection.
The new package containing the fixes is available in Lunar for many days now and no issues like the aforementioned
ones were reported.
In order to mitigate the regression potential, the results of the
aforementioned integration tests are attached to this bug.
[Other Info]
There are remaining known bugs on "netplan set" that were detected recently but we confirmed they
are not regressions caused by this patch as they were already present in netplan. They are all
documented in LP: #2003727.
The issues addressed by this SRUs are the only ones causing real
impact to customers based on LP bug reports.
[Changelog]
Bug fixes:
- d/p/lp1997467: set only specific origin-hint if given (LP: #1997467)
Cherry-picked from upstream: https://github.com/canonical/netplan/pull/299
- d/libnetplan0.symbols: Add netplan_parser_load_nullable_overrides() API
==== Original report ====
Sorry that this is a bit unspecific right now, I will try to provide
more details ASAP.
We see failures in our nested core20-early-config test, e.g.
https://github.com/snapcore/snapd/actions/runs/3512986269/jobs/5885568960
The test fails in the following place:
"""
...
+ remote.exec 'sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=false'
+ MATCH false
+ remote.exec sudo 'netplan get bridges.br54.dhcp4'
grep error: pattern not found, got:
true
"""
at this point the files look like this (sudo is now needed which was not before btw):
"""
$ sudo cat /etc/netplan/0-snapd-defaults.yaml
network:
version: 2
ethernets:
ens3:
addresses:
- "10.0.2.15/24"
dhcp4: false
routes:
- to: "default"
via: "10.0.2.2"
bridges:
br54:
dhcp4: true
$ sudo cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enp0s2:
dhcp4: true
match:
macaddress: '52:54:00:12:34:56'
set-name: enp0s2
version: 2
"""
When I manually run
$ sudo snap set system
system.network.netplan.network.bridges.br54.dhcp4=false
inside the VM I see no error but the file 0-snapd-defaults.yaml is unchanged and no
new file 90-snapd-config is created. The logic inside snapd is that the gadget defaults
are stored as 0-snapd-defaults and later changes are stored in 90-sanpd-config so that
the later config values win over the earlier ones.
Fwiw, this test is also run on a core20 system with netplan 104 and
there the same test works succesfully afaict.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1997467/+subscriptions
More information about the Ubuntu-sponsors
mailing list