[regression] netplan apply is not idempotent and fails trying to rename a bond member interface
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Netplan |
Fix Released
|
High
|
Mathieu Trudel-Lapierre | ||
netplan.io (Ubuntu) |
Fix Released
|
High
|
Mathieu Trudel-Lapierre | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned |
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:
- enp4s0f0
- enp5s0f0
mtu: 9000
enp4s0f0:
match:
mtu: 9000
enp5s0f0:
match:
mtu: 9000
[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:/
juju model-config logging-
2018-11-08 13:44:10 DEBUG juju.network.
File \"/usr/
netplan.main()
File \"/usr/
self.
File \"/usr/
self.func()
File \"/usr/
self.
File \"/usr/
self.func()
File \"/usr/
stderr=
File \"/usr/
raise CalledProcessEr
subprocess.
" "" 1
From the Juju machine agent code:
command := fmt.Sprintf(
// ...
logger.
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://
bond0:
- enp4s0f0
- enp5s0f0
enp4s0f0:
match:
mtu: 9000
enp5s0f0:
match:
mtu: 9000
curtin config:
http://
# ip addr show enp5s0f0
8: enp5s0f0: <NO-CARRIER,
link/ether 00:0a:f7:72:a7:28 brd ff:ff:ff:ff:ff:ff
# ip addr show enp4s0f0
6: enp4s0f0: <BROADCAST,
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.
Changed in netplan.io (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
Changed in netplan: | |
assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
importance: | Undecided → High |
status: | New → Triaged |
tags: | added: regression-release |
tags: |
added: regression-update removed: regression-release |
tags: | added: id-5be4a491c40aa00e98bc940a |
description: | updated |
Subscribed ~field-critical as it blocks field deployments and does not have a workaround.