maas provider assumes machine uses dhcp for eth0

In the mid- to long-term juju will be more flexible in the networking setup and allow static IPs and bridges to be configured as needed (not only for MAAS), but this will come along as we implement more of the networking model.

In the short-term, I propose to implement a "safety switch" environment setting (a flag, false by default) "disable-network-management", which when set will prevent juju from trying to configure or manage networking on the machines AT ALL (i.e. the networker will run in safe mode and the maas provider in particular won't change the networking setup during cloudinit). This should fix your immediate issue.

Off-topic: There seems to be some misunderstanding, as as far as I know it was decided to allow juju to manage the networking in a maas environment (at least for this cycle). If both Juju and MAAS try to manage networking there are bound to be issues and we need to work together more closely.

Just to add a small point.

There is another "be safe in what you do" where if we try to bring something down, and then have a failure, we should *really* try to bring that thing back up again, which I think would actually have fixed the problem here as well.

The other change that I've proposed internally is that we don't try to configure br0 until we actually want LXC machines on a given system, which should also help with this.

Probably this is at least partially hard because we are configuring br0 in cloud init in existing releases, rather than doing it in the agent, though that should be changing for 1.21.

So I'd say we can take a few approaches and we should probably do more than one:

1) our code that tries to configure eth0 should fail safe and not leave eth0 down
2) we can have an environment flag to disable automatic network management
3) we should not reconfigure a bridge until we know that we actually want to put containers on the machine
4) we should be configuring the bridge inside of the jujud agent and not in cloud-init