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

[Daniel Bidwell]

When juju installs juju-br0 on a machine that doesn't have any ethX interfaces it fails to bring up the juju-br0 interface. I have a set of machines that have em[0-3] interfaces and I have to manually edit the /etc/network/interfaces to fix them.

[Curtis Hovey (sinzui)]

Which version of juju are you using?

[Dimiter Naydenov (dimitern)]

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

[Dimiter Naydenov (dimitern)]

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.

[Dimiter Naydenov (dimitern)]

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.

[Buddy Yaussy (ly9056)]

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

[Buddy Yaussy (ly9056)]

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

[Adam Stokes (adam-stokes)]

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

[Nathan Owens (6-nathan)]

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.

[elliot (rs-5)]

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

[Nathan Owens (6-nathan)]

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

[Dimiter Naydenov (dimitern)]

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)?

[Buddy Yaussy (ly9056)]

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?

[Dimiter Naydenov (dimitern)]

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

[Buddy Yaussy (ly9056)]

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...

[Buddy Yaussy (ly9056)]

Never mind -- Adam squared me away.

[Buddy Yaussy (ly9056)]

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

[Adam Stokes (adam-stokes)]

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

[Curtis Hovey (sinzui)]

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.

[Alexander List (alexlist)]

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.

[Haw Loeung (hloeung)]

Is it possible to backport the fix to 1.22?

[Haw Loeung (hloeung)]

| 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.

[Anastasia (anastasia-macmood)]

targeted against old milestone