** Description changed: + [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) + 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 + 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 + 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 + 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 + 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. + This is currently blocking all of our bionic deployments as all of them + have bonds.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1802322 Title: [regression] netplan apply is not idempotent and fails trying to rename a bond member interface To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1802322/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
