cloud-init network error when using MAAS/juju
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Expired
|
Medium
|
Scott Moser | ||
juju-core |
Fix Released
|
Medium
|
Dimiter Naydenov |
Bug Description
I am setting up a testing environment for Trusty, MAAS and juju, all on KVM's. I provisioned 5 machines through MAAS and juju add-machine, all went fine.
When the systems reboot - all 5 of them - the network configuration fails and thus the cloud init. You get the "cloud-init-nonet wating for 120 seconds ..." and then the subsequent "gave up waiting ..." messages.
I added some outputs to cloud-init-nonet, for that the funny lines in the boot.log. What is interesting that after all the wating and doing things, finally you get a login prompt. And the network is up as it should!
I added bridge_maxwait 0 to the br0 stanza in /etc/network/
I have tested the br0 configuration on a fresh 14.04 server installation with no cloud features and it works without any changes.
I thought maybe firewall issues, so I removed ufw.conf for a change - reboot was the same.
All used packages used are the latest 14.04 repositories, freshly updated.
Related bugs:
* bug 1031065: cloud-init-nonet runs 'start networking' explicitly
* bug 800824: cloud-init-nonet times out in lxc
* bug 925122: container's udevadm trigger --add affects the host
* bug 643289: idmapd does not starts to work after system reboot
Changed in cloud-init: | |
status: | Incomplete → New |
tags: | added: network |
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → High |
tags: | added: cloud-installer landscape |
tags: | removed: cloud-installer landscape |
Changed in cloud-init: | |
status: | New → In Progress |
assignee: | nobody → Scott Moser (smoser) |
importance: | Undecided → High |
Changed in juju-core: | |
importance: | High → Medium |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
There is a lot of information missing from your bug report.
I'm not sure how 'br0' comes into play at all here.
Unless you've modified something, the installed system will not expect or use a 'br0'. And if you *have* modified something, then you're going to need to explain what that is that you've modified.
cloud-init-nonet upstart job blocks further boot until all 'auto' network adapters in /etc/network/ interfaces (including those sourced from /etc/network/ interfaces. d/*) are up. That is by design and I suspect not broken.