juju-br0 is not configured correctly on maas machines without ethX interfaces

Which version of juju are you using?

Also, please provide logs from a newly started machine starts: /var/log/cloud-init-output.log, /var/log/juju/*.log

Related bug #1423626

jamespages, myself and Murali were discussing the issue on #juju and it turned out the problem is most likely caused by using the debian installer to deploy the nodes in maas, rather than the fast installer. The former sets the "biosdevname" apt policy which leads to renaming ethX interfaces to emX, unlike the latter.

I'm investigating now on my local kvm-based maas:
1. disabling "use fast installer" on previously commissioned node and bootstrapping juju on it
2. disabling the fast installer, recommissioning the node and then deploying

I'll update the bug with my results.

Update: due to some (recent) changes in the maas provider in trunk switching to the debian (slow) installer causes the bootstrap to fail with:
...
2015-02-19 17:07:52 DEBUG juju.environs cloudinit.go:171 Setting numa ctl preference to false
2015-02-19 17:07:52 DEBUG juju.provider.maas environ.go:931 maas user data; 1222 bytes
2015-02-19 17:07:53 DEBUG juju.provider.maas environ.go:936 started instance "/MAAS/api/1.0/nodes/node-fc3bdec0-c163-11e3-84a7-525400355a63/"
2015-02-19 17:07:53 DEBUG juju.provider.common state.go:36 putting "provider-state" to bootstrap storage *maas.maasStorage
 - /MAAS/api/1.0/nodes/node-fc3bdec0-c163-11e3-84a7-525400355a63/
2015-02-19 17:11:58 ERROR juju.cmd supercommand.go:411 failed to bootstrap environment: bootstrap instance started but did not change to Deployed state: instance "/MAAS/api/1.0/nodes/node-fc3bdec0-c163-11e3-84a7-525400355a63/" is started but not deployed

That's despite having "bootstrap-timeout: 1200" [s] in my environments.yaml. But that's another story.

Some minutes after juju gave up, the node finished installing and I can confirm after SSH-ing in and running "apt-cache policy biosdevname" that it's installed (unlike before). But the network interfaces everywhere are still called ethX rather than emX as I expected. This is juju 1.23-alpha1-trusty-amd64 and maas 1.8-alpha from rvba's ppa.

Having the same issue. Installing on Dell Poweredge R720xd servers

Ubuntu Server 14.04.2
juju: 1.21.3-trusty-amd64

Here are the requested logs:
/var/log/cloud-init-output.log: http://pastebin.com/4rvbdQ6Y
/var/log/juju/all-machines.log: http://pastebin.com/KTGtCru1
/bar/log/juju/machine-0.log: http://pastebin.com/fBd08DxV

Having the same issue. See requested logs below.

Running juju/stable from this morning: 1.21.3-trusty-amd64

/var/log/cloud-init-output.log: http://pastebin.com/4rvbdQ6Y
/var/log/juju/all-machines.log: http://pastebin.com/KTGtCru1
/var/log/juju/machine0.log: http://pastebin.com/fBd08DxV

This is also blocking users attempting to deploy OpenStack via the installer multi option (MAAS+Juju)

I believe the issue lies here: https://github.com/juju/juju/blob/48b760792931378b2de85ef070bf0ec6b9913c20/worker/provisioner/lxc-broker.go#L435

finalIfaceInfo[i].InterfaceName = fmt.Sprintf("eth%d", finalIfaceInfo[i].DeviceIndex)

It is hard coded to use "eth*"

This also shows up here:
https://github.com/juju/juju/blob/9f0b294191075f6cf30648bb5884a03a2da9a87a/state/state_test.go#L1688
https://github.com/juju/juju/blob/ea7c74e57ac552cfe378eca69ece53c2ef042f53/provider/dummy/environs.go#L941
https://github.com/juju/juju/blob/ea7c74e57ac552cfe378eca69ece53c2ef042f53/provider/dummy/environs.go#L1104
https://github.com/juju/juju/blob/ea7c74e57ac552cfe378eca69ece53c2ef042f53/provider/dummy/environs.go#L1108

I may attempt to put together a patch, but i'm not sure of the best way to go about it yet.

Thanks to a colleague of mine (Mitch) I finally found a solution:

Simply set the "Global Kernel Parameters - Boot parameters to pass to the kernel by default" (settings of MAAS) to

net.ifnames=0 biosdevname=0

With this settings interfaces are not renamed but left as ethX

Unfortunately doing this changes the names of read-only disks like the CD-rom drive, and breaks the Ubuntu cloud-install with this bug: https://bugs.launchpad.net/charms/+source/ceph/+bug/1420094

In juju 1.23-beta1 juju-br0 is no longer created, so this shouldn't be a problem anymore. Can you verify if an issue still exists with juju 1.23 (once it gets released I guess)?

I'll verify as soon as I can get my hands on 1.23. Any idea how when 1.23-beta1 might be available to try?

@ly9056: 1.23-beta1 is planned for release tomorrow as I understood today.

Looks like the release got posted yesterday, but I'm not sure what to do with it as it's just a source tarball. I am a developer, but not familiar with this project. How do I build and then make use of the juju-core source to test if this got fixed? My extent of experience with juju is installing it with apt and letting the cloud installer do the rest...

Never mind -- Adam squared me away.

I can verify that 1.23-beta1 has fixed this issue for me. I am now able to bootstrap juju to a MAAS node deployed on bare metal hardware using the new interface names (em1, em2, p3p1, p3p2, etc.) and no interface assigned eth0

There's also been another report of this problem resolved in 1.23-beta1.

https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/349#issuecomment-86087121

Though this issue is fixed in 1.23-beta1, I am targeting this bug to 1.23-beta2 so that it is included in the announcements.

I see the same behaviour with juju-core 1.22.1 on 14.04 against MAAS.

I am trying to deploy OpenStack with infra deployed into LXC containers (smoosh), the infra node (bare metal) has network interfaces named emX.

Is it possible to backport the fix to 1.22?

| In juju 1.23-beta1 juju-br0 is no longer created, so this shouldn't be
| a problem anymore. Can you verify if an issue still exists with juju
| 1.23 (once it gets released I guess)?

This doesn't appear to be the case. I've tried 1.24.5-trusty-amd64 from the juju stable PPA and it seems juju-br0 was still being created.

targeted against old milestone