Comment 32 for bug 1271144

There has been a lot of activity on this bug with more than one issue involved and so I just wanted to confirm:

This problem still exists with maas 1.5.2+bzr2282 and juju 1.18.1 (the current stable releases) when you bootstrap a node with trusty.

Therefore, it breaks Canonical's OpenStack "Golden Happy Path". What I mean by that is, if you went to Canonical's web site and followed the instructions for deploying OpenStack using the latest stable, updated software (trusty, maas, and juju), then you will fail due to this bug. Right? Or is there anyone out there who is able to bootstrap juju correctly (br0 comes up) on Trusty via MaaS right now with the latest software?

Also, it's very difficult to know what software component is at fault so you can report the problem or look for existing bugs. Even if you guessed it was juju, this bug doesn't even show up on the default list of bugs because it's marked "Fix Released" as it primary status.

BTW, I doubt that the fix for #1337091 will fix this issue with trusty because even if I force my new trusy NIC names (em1, etc) back to eth0 using biosdevname=0 boot option and manually configure /etc/network/interfaces and reboot, then br0 is still not brought up when it should. The result is that cloud-init-nonet complains about the network not being up. Note that immediately after cloud-init-nonet gives up, ifup -a is run (by whom is a total mystery as the parent process is 1) and then br0 finally comes up but its too late.

I tried to debug the problem but I cannot find any documentation as to what the boot sequence for networking is supposed to be when juju/cloud-init is involved. I notice that some hardware interfaces are brought up due to udev events, but the software bridges are not brought up until later. I guess that's why the cloud init scripts try to bring up br0 on their own. Except its not happening. Are the cloud-init scripts supposed to bring up br0 on every boot or just after the first boot when it munges the network config?

Since this bug involves different issues, it's not clear whether anyone is still working on this (the Trusty target is Unassigned) or is even aware that a problem still exists.

For all these reasons, this bug is very frustrating. It would be very helpful if someone could provide status as to what is being or will been done to resolve it. If folks are still not convinced that a real problem is still outstanding, I have equipment and time and can provide whatever information and will follow whatever instructions are necessary to change their minds. If I've done something wrong, I'm eager to determine what it was. Also, if it is unreasonable to expect 14.04 deployments to work anytime soon, please let me know and I'll go back to deploying 12.04 for now.