Containers stuck allocating, interface not up
Bug #1438683 reported by
Adam Collard
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
juju-core | Status tracked in Trunk | |||||
1.23 |
Fix Released
|
High
|
Michael Foord | |||
Trunk |
Fix Released
|
High
|
Michael Foord |
Bug Description
Container's eth0 doesn't come up, and gets stuck in "allocating" forever.
Juju status output - https:/
Commissioning data (LSHW output) from MAAS - http://
machine-0.log - WARNING: this is a 12Mb text file! http://
LXC config - http://
LXC console log - http://
Changed in juju-core: | |
assignee: | nobody → Michael Foord (mfoord) |
Changed in juju-core: | |
status: | Triaged → In Progress |
Changed in juju-core: | |
status: | In Progress → Fix Committed |
no longer affects: | juju-core (Ubuntu) |
Changed in juju-core: | |
milestone: | 1.23-beta3 → 1.24-alpha1 |
milestone: | 1.24-alpha1 → 1.23-beta3 |
no longer affects: | juju-core (Ubuntu) |
Changed in juju-core: | |
milestone: | 1.23-beta3 → 1.24-alpha1 |
milestone: | 1.24-alpha1 → 1.23-beta3 |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
no longer affects: | juju-core/1.23 |
no longer affects: | juju-core/trunk |
no longer affects: | juju-core/trunk |
no longer affects: | juju-core/1.23 |
To post a comment you must log in.
Preliminary analysis:
1) lshw XML parsing does not work correctly when there are multiple "network" elements without id suffix (i.e. the maas provider expects to find either a single <nod id="network"> element or more than one element, but with the format <node id="network:0">, <node id="network:1">, etc.). The result of this is the DeviceIndex is always 0 for all NICs when the lshw output only contains un-prefixed network nodes (see the lshw paste above)
2) The reason why the eth0 interface of the container is not up is because the generated lxc config does not include "lxc.network.flags = up", and that's because for some unknown reason juju picks the disabled eth1 rather than eth0 as host NIC.
3) Both eth0 and eth1 on the host are on the same network - this might be relevant for the way maas provider / provisioner works now (e.g. it discovers 2 subnets named "maas-br0", which is just the same network), but because of ordering or something else the provisioner picks the incorrect host nic to use (eth1 rather than eth0) - might be related to the device index issue as the container's NIC name is generated from the host's primary NIC's index.