AWS - instances getting ens3 vs eth0

[james beedy]

Some instances are getting ens3, some get eth0. The instances that end up with ens3 have failing lxd deploys when you try to deploy lxd to them via `juju deploy ubuntu ubuntu-lxd --to #`.

I can only get instances with interfaces named ethX not on *my* aws account/creds. I have to switch to my charm dev creds (Canonical aws account) to get instances to deploy with devices named ethX.

here is an instance with lxd failing (ens3) http://paste.ubuntu.com/24415263/

here is an instance with lxd working (eth0) http://paste.ubuntu.com/24415265/

This is slightly critical, as its happening for me across all availability zones in us-east-1 and us-east-2, and is blocking me from being able to deploy any lxd on AWS in these regions (a good portion of my infra/ops are in this realm).

Possibly we can pull from the maas provider ... I'm thinking there is already a good solution to dissimilar interface names for maas.
  - It looks like maas returns the information about the machine's device names to juju ... this must be why/how juju can handle the different device naming convention using the maas provider.

Possibly we could just extend the aws provider to handle both ensX and ethX devices?

[james beedy (jamesbeedy)]

@jameinel, @rharding ^

[Menno Finlay-Smits (menno.smits)]

Possibly/likely related to bug 1684143.

[John A Meinel (jameinel)]

might just be https://bugs.launchpad.net/juju/+bug/1668547

[John A Meinel (jameinel)]

'ens3' should *not* be a problem for us, as we should just be going off of the devices that we find. I have the feeling that machines coming up with 'ens3' have some other subtle (not so subtle) difference that is causing problems.

[james beedy (jamesbeedy)]

@jmeinel xref -> https://bugs.launchpad.net/juju/+bug/1684143/comments/8