[Bug 1802322] Re: [regression] netplan apply is not idempotent and fails trying to rename a bond member interface

Steve Langasek steve.langasek at canonical.com
Fri Mar 29 01:15:42 UTC 2019


Hello Dmitrii, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.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 and change the tag from
verification-needed-cosmic to verification-done-cosmic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-cosmic. 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.

** Changed in: netplan.io (Ubuntu Cosmic)
       Status: Fix Released => Fix Committed

** Tags removed: verification-done verification-done-cosmic
** Tags added: verification-needed verification-needed-cosmic

** Changed in: netplan.io (Ubuntu Bionic)
       Status: Fix Released => Fix Committed

** Tags removed: verification-done-bionic
** Tags added: verification-needed-bionic

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

Title:
  [regression] netplan apply is not idempotent and fails trying to
  rename a bond member interface

Status in netplan:
  Fix Released
Status in netplan.io package in Ubuntu:
  Fix Released
Status in netplan.io source package in Bionic:
  Fix Committed
Status in netplan.io source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]
  Usage of juju to deploy systems with bridge configurations is severely broken if using layer3+4 bonding, as renaming might be attempted and break the application of config.

  [Test case]
  1) Deploy a system using MaaS and Juju, with a network configuration such as:
          bond0:
              interfaces:
              - enp4s0f0
              - enp5s0f0
              macaddress: 00:0a:f7:72:a7:28
              mtu: 9000
              parameters:
                  down-delay: 0
                  lacp-rate: fast
                  mii-monitor-interval: 100
                  mode: 802.3ad
                  transmit-hash-policy: layer3+4
                  up-delay: 0

          enp4s0f0:
              match:
                  macaddress: 00:0a:f7:72:a7:28
              mtu: 9000
              set-name: enp4s0f0

          enp5s0f0:
              match:
                  macaddress: 00:0e:1e:ac:67:00
              mtu: 9000
              set-name: enp5s0f0

  
  [Regression potential]
  This fix is to correct an existing regression. Changes in the rename code might otherwise impact the effect of attempting to rename interfaces when (and only when) 'netplan apply' is being run, which only ever happens as directed by the user (either directly at the command-line or via scripting such as via juju). Changes are limited to the behavior of 'netplan apply' in the interface renaming step; and the fix has been to ignore non-physical devices (which are not renamed anyway, but created) and physical devices members of a bond/bridge.

  ---

  After an update for https://bugs.launchpad.net/netplan/+bug/1770082
  was released for bionic and our systems started getting the new
  packages, *clean* MAAS + Juju + Bionic + LXD container deployments
  started to fail on bridge activation.

  juju model-config logging-
  config='<root>=WARNING;unit=DEBUG;juju.network.netplan=TRACE'

  2018-11-08 13:44:10 DEBUG juju.network.netplan activate.go:99 Netplan activation result "Traceback (most recent call last):
    File \"/usr/sbin/netplan\", line 23, in <module>
      netplan.main()
    File \"/usr/share/netplan/netplan/cli/core.py\", line 50, in main
      self.run_command()
    File \"/usr/share/netplan/netplan/cli/utils.py\", line 130, in run_command
      self.func()
    File \"/usr/share/netplan/netplan/cli/commands/apply.py\", line 43, in run
      self.run_command()
    File \"/usr/share/netplan/netplan/cli/utils.py\", line 130, in run_command
      self.func()
    File \"/usr/share/netplan/netplan/cli/commands/apply.py\", line 102, in command_apply
      stderr=subprocess.DEVNULL)
    File \"/usr/lib/python3.6/subprocess.py\", line 291, in check_call
      raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['ip', 'link', 'set', 'dev', 'enp5s0f0', 'name', 'enp4s0f0']' returned non-zero exit status 2.
  " "" 1

  From the Juju machine agent code:

  command := fmt.Sprintf("%snetplan generate && netplan apply && sleep 10", params.RunPrefix)
  // ...
  logger.Debugf("Netplan activation result %q %q %d", result.Stderr, result.Stdout, result.Code)

  The rename operation in question does not seem to be justified by
  anything that juju would want to do.

  Inspecting closer it can be seen that 00:0a:f7:72:a7:28 is a mac
  address of enp4s0f0 which also happens to be a MAC address of the bond
  and gets applied to all members of a bond (enp5s0f0 is of specific
  interest) after the first run of netplan after the deployment.

  It looks like a subsequent `netplan generate && netplan apply`
  invocation by Juju causes netplan to try to apply "enp4s0f0" name to
  "enp5s0f0" interface because it has "00:0a:f7:72:a7:28" for a mac
  address as a result of becoming a bond member.

  netplan generated by cloud-init:
  http://paste.ubuntu.com/p/QfR4f5yMYP/

          bond0:
              interfaces:
              - enp4s0f0
              - enp5s0f0

  
          enp4s0f0:
              match:
                  macaddress: 00:0a:f7:72:a7:28
              mtu: 9000
              set-name: enp4s0f0

          enp5s0f0:
              match:
                  macaddress: 00:0e:1e:ac:67:00
              mtu: 9000
              set-name: enp5s0f0

  curtin config:
  http://paste.ubuntu.com/p/NkvZKqZYjr/

  # ip addr show enp5s0f0
  8: enp5s0f0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9000 qdisc mq master bond0 state DOWN group default qlen 1000
      link/ether 00:0a:f7:72:a7:28 brd ff:ff:ff:ff:ff:ff

  # ip addr show enp4s0f0
  6: enp4s0f0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP group default qlen 1000
      link/ether 00:0a:f7:72:a7:28 brd ff:ff:ff:ff:ff:ff

  This is currently blocking all of our bionic deployments as all of
  them have bonds.

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



More information about the foundations-bugs mailing list