[Bug 1802322] Re: [regression] netplan apply is not idempotent and fails trying to rename a bond member interface
Launchpad Bug Tracker
1802322 at bugs.launchpad.net
Thu Nov 22 04:01:32 UTC 2018
This bug was fixed in the package netplan.io - 0.90
---------------
netplan.io (0.90) disco; urgency=medium
* New upstream release:
- build: fixes for building on RPM-based distros
- build: code prettiness changes (make indentation consistent)
- Fix device name-changes detection (LP: #1770082)
- Add support for IPv6 Privacy Extensions (LP: #1750392)
- Add dhcp{4,6}-overrides to control DNS, NTP, hostname updates via DHCP
(LP: #1759014)
- Clarify MAC and MTU setting requirements (LP: #1800668)
- Various documentation fixes (LP: #1800669)
- Improve error reporting to give clearer messages and context
(LP: #1800670)
- Skip non-physical/bond interfaces when applying renames (LP: #1802322)
-- Mathieu Trudel-Lapierre <cyphermox at ubuntu.com> Wed, 21 Nov 2018
14:06:13 -0500
** Changed in: netplan.io (Ubuntu)
Status: Triaged => 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/1802322
Title:
[regression] netplan apply is not idempotent and fails trying to
rename a bond member interface
Status in netplan:
Triaged
Status in netplan.io package in Ubuntu:
Fix Released
Bug description:
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