juju/juju — pull request #1046 by dimitern (2014-11-05 09:35:56+00:00)
Title: Fixed LXC/KVM bridge settings for maas and other environments

This PR aims to address a number of bugs all related to LXC or
KVM containers on MAAS nodes not getting IP addresses, got stuck
in "pending" or failed to start due to networking issues:
* http://pad.lv/1368976
* http://pad.lv/1271144
* http://pad.lv/1386189
* http://pad.lv/1340261
* http://pad.lv/1386575
* http://pad.lv/1345433

Most of the issues arise from the way Juju creates a "br0" bridge
device and attaches the "eth0" interface on the machine to it, so
containers can use DHCP to acquire an IP address from MAAS. However,
after lots of testing the following fixes and changes were done:
* Removed the "network-bridge" MAAS environment setting (introduced
in #227). This setting has a misleading name (it's supposed to
allow users to pick which network interface on the machine to
attach to the bridge, not the name of the bridge itself) and
cannot work as intended (machines have different network interfaces
in general). The impact of this change should be minimal, as it
was never used properly.
* A few changes made to common.Bootstrap and cloudinit.FinishMachineConfig.
BootstrapParams struct now has a "ContainersBridgeName" field. When
set, it will cause the LXC_BRIDGE setting in the agent config on the
bootstrap node to have the given value. Because the LXC_BRIDGE setting
is used to determine the network bridge name for starting both LXC and
KVM containers, setting ContainersBridgeName at bootstrap time (as the
MAAS provider does now) will override the silent defaults otherwise
used ("lxcbr0" for LXC and "virbr0" for KVM containers).
* MAAS provider changes simplified the generated cloudinit scripts (e.g.
do not try to "restore" network interfaces file before adding the
bridge config), a single "juju-br0" bridge is created and set to get
an address using DHCP from the machine's primary network interface.
* Added code to discover the primary NIC from the lshw data MAAS holds.
This should work in most cases, including with more complex networking
setup per node (e.g. using custom preseed or commissioning scripts).
* I discovered the networker worker is not starting for machines deployed
after bootstrap due to a missing JobManageNetworking (see DeployService
and AddUnits), but that's fine because it was interfering with the bridge
network config generated at cloudinit time.
So, as a temporary measure, no JobManangeNetworking will be added to the
bootstrap nodes by default and the networker will only work in "safe mode".

I spend the last 3 days extensively testing the changes with live environments
on MAAS, EC2, and local, to ensure no regressions are introduced and both
LXC and KVM containers get proper addresses on MAAS.