[Bug 1997467] Please test proposed package

Wed Feb 15 08:11:39 UTC 2023

Hello Michael, or anyone else affected,

Accepted netplan.io into jammy-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/netplan.io/0.105-0ubuntu2~22.04.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
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 Released
Status in netplan.io package in Ubuntu:
  Fix Released
Status in netplan.io source package in Jammy:
  Fix Committed
Status in netplan.io source package in Kinetic:
  Fix Committed
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