[Bug 1949893] Re: new interface does not show up after dbus config apply

Tue Nov 30 05:39:57 UTC 2021

This bug was fixed in the package netplan.io - 0.103-0ubuntu10

---------------
netplan.io (0.103-0ubuntu10) jammy; urgency=medium

  * update gbp.conf branch
  * Drop d/p/0002-Revert-cli-apply-reload-reconfigure-networkd-instead.patch
    This is not needed anymore with systemd v249
  * Refresh d/p/0006-netplan-set-make-it-possible-to-unset-a-whole-devtyp.patch
  * Add d/p/0012-test-bridge-base-give-bridge-some-more-time-to-reach.patch
    To fix flaky test_bridge_anonymous autopkgtest (upstream c6ad8e6)
  * Upstream cherry-picks for snapd dbus config set-try-apply integration fixes
    - dbus-wait-for-netplan-try-to-be-ready-LP-1949893-245.patch (LP: #1949893)
    - get-set-ignore-empty-YAML-hints-and-delete-files-on-.patch (LP: #1946957)

 -- Lukas Märdian <slyon at ubuntu.com>  Mon, 29 Nov 2021 17:14:32 +0100

** Changed in: netplan.io (Ubuntu Jammy)
       Status: New => 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/1949893

Title:
  new interface does not show up after dbus config apply

Status in netplan:
  In Progress
Status in netplan.io package in Ubuntu:
  Fix Released
Status in netplan.io source package in Focal:
  New
Status in netplan.io source package in Hirsute:
  New
Status in netplan.io source package in Impish:
  New
Status in netplan.io source package in Jammy:
  Fix Released

Bug description:
  [Impact]
  snapd uses netplan's DBus API to create config objects and set/try/apply changed configuration.

  There is a race condition in io.netplan.Netplan.Config.Try() that
  returns the DBus call too early, when the 'netplan try' subprocess
  call is not yet fully executed. There it can happen that interfaces
  are not fully created or set-up after the DBus call finished.

  [Test Plan]
  In addition to running & passing the full set of unit- and integration-tests (that contains new tests to check for the cases described in this bug), as described in https://wiki.ubuntu.com/NetplanUpdates we want to run the two reproducer script from #3 and make sure it passes and creates the br54 interface successfully and in time:

  $path=$(dbus-send --system --print-reply --type=method_call
  --dest=io.netplan.Netplan /io/netplan/Netplan
  io.netplan.Netplan.Config|grep path|cut -f2 -d'"')

  $ dbus-send --system --print-reply --type=method_call --dest=io.netplan.Netplan "$path" io.netplan.Netplan.Config.Set string:"network.bridges.br54.dhcp4=true" string:"90-snapd-conf"
  $ dbus-send --system --print-reply --type=method_call --dest=io.netplan.Netplan "$path" io.netplan.Netplan.Config.Try uint32:30
  $ sleep 0.1
  $ dbus-send --system --print-reply --type=method_call --dest=io.netplan.Netplan "$path" io.netplan.Netplan.Config.Apply

  $ ip link | grep br54

  autopkgtest logs:
  * Impish:
  TBD: amd64, arm64, armhf, ppc64el, s390x

  * Hirsute:
  TBD: amd64, arm64, armhf, ppc64el, s390x

  * Focal:
  TBD: amd64, arm64, armhf, ppc64el, s390x

  [Where problems could occur]
  This upload contains changes to the netplan-dbus daemon and try+apply CLI of netplan, if anything goes wrong it could impact the interactive usage of 'netplan try/apply' by the user and the programmatic access to netplan's APIs via DBus.

  [Other Info]
  The full set of autopkgtest logs will be attached after the upload is accepted into -proposed and the tests have been run on the official autopkgtest.u.c
  infrastructure.

  === Original Description ===
  While working on the integration tests for netplan on ubuntu core I ran into the following issue:
  1. the config system.network.netplan.network.bridges.br54.dhcp4=true is set
  2. a subsequent "ip link" does not show this network interface

  From the test log:
  """
  ...
  + echo 'Check that setting adding a br54 interface via netplan works'
  Check that setting adding a br54 interface via netplan works
  + snap set system system.network.netplan.network.bridges.br54.dhcp4=true
  + echo 'Check that the interface is really there'
  Check that the interface is really there
  + MATCH br54
  + ip link
  grep error: pattern not found, got:
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
      link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
  """

  But when I ssh into this machine:
  """
  qemu:ubuntu-core-20-64 .../tests/core/netplan-cfg# netplan get
  network:
    bridges:
      br54:
        dhcp4: true
    ethernets:
      all-en:
        dhcp4: true
        match:
          name: en*
      all-eth:
        dhcp4: true
        match:
          name: eth*
    version: 2
  """
  So the interfac is there but not applied.

  What the go code is doing internally (using dbus) is:
  1. clear config
  2. set new config
  3. call io.netplan.Netplan.Config.Try with a 30s timeout
  4. check if store is still reachable
  5. run io.netplan.Netplan.Config.Apply

  Log:
  """
  Nov 04 18:35:56 ubuntu snapd[2864]: daemon.go:216: DEBUG: pid=3308;uid=0;socket=/run/snapd.socket; GET /v2/snaps/system/conf?keys=system.network.netplan.network.version 188.318703ms 200
  Nov 04 18:35:56 ubuntu snapd[2864]: netplan.go:122: DEBUG: using netplan config /io/netplan/Netplan/config/WCELC1
  Nov 04 18:35:57 ubuntu snapd[2864]: daemon.go:216: DEBUG: pid=3321;uid=0;socket=/run/snapd.socket; GET /v2/snaps/system/conf?keys=system.network.netplan 250.060706ms 200
  Nov 04 18:35:57 ubuntu snapd[2864]: daemon.go:216: DEBUG: pid=3348;uid=0;socket=/run/snapd.socket; PUT /v2/snaps/system/conf 5.846868ms 202
  Nov 04 18:35:57 ubuntu snapd[2864]: taskrunner.go:439: DEBUG: Running task 149 on Do: Run configure hook of "core" snap
  Nov 04 18:35:57 ubuntu snapd[2864]: netplan.go:122: DEBUG: using netplan config /io/netplan/Netplan/config/MYV8B1
  Nov 04 18:35:57 ubuntu snapd[2864]: netplan.go:122: DEBUG: using netplan config /io/netplan/Netplan/config/V1VAC1
  Nov 04 18:35:57 ubuntu snapd[2864]: netplan.go:181: DEBUG: calling netplan.Set: network=null
  Nov 04 18:35:57 ubuntu snapd[2864]: netplan.go:181: DEBUG: calling netplan.Set: network={"bridges":{"br54":{"dhcp4":true}},"ethernets":{"all-en":{"dhcp4":true,"match":{"name":"en*"}},"all-eth":{"dhcp4":true,"match":{"name":"eth*"}}},"version":2}
  ...
  Nov 04 18:35:58 ubuntu snapd[2864]: netplan.go:229: DEBUG: netplan config applied correctly
  """
  The originHint for all of these is "00-snapd-config.yaml"

  But the interface does not appear.

  But a subsequent:
  ""
  qemu:ubuntu-core-20-64 .../tests/core/netplan-cfg# netplan apply --debug
  [notice that there is no output here? sorry, I was holding it wrong and filed https://bugs.launchpad.net/netplan/+bug/1949895 about that]

  qemu:ubuntu-core-20-64 .../tests/core/netplan-cfg# ip link
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
      link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
  3: br54: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
      link/ether 32:b4:1e:6a:73:ba brd ff:ff:ff:ff:ff:ff
  """

  and the interface appears. Any hints welcome, this is netplan
  "0.103-0ubuntu5~20.04.2" - I think this code was working before (well,
  it would cause crashes later but this bit iirc worked).

  Any hints welcome :)

  Details for how netplan dbus is driven can be found in
  https://github.com/snapcore/snapd/pull/10752/files#diff-c86917f7728e51b6582063142105b47a9a2677b252a9928b3c37b3b353839ac7R161

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