-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
TL;DR: As of yesterday, xenial cloud images no longer have an eth0
interface, but one named by systemd instead. cloud-init should handle
DHCP'ing on it in the simple case, but you will need to update scripting
which assumes eth0's existence. Sorry for the lateness of the change!
In wily, support for systemd's predictable interface naming was
introduced to Ubuntu.
This broke the majority of clouds and cloud images, where it was assumed
that eth0 will exist and be the primary interface. As such, we made the
decision to disable predictable interface naming in wily (by setting
net.ifnames=0 in the default grub command line on cloud images), thereby
taking on a delta from the server image in the cloud images.
We did this with the understanding that this delta was unsupportable for
a five year LTS cycle, and that it would be reverted during the xenial
cycle. To enable us to use the predictable interface names, cloud-init
would learn to dynamically discover interfaces on boot, and configure
DHCP on the "first" of them; this would mimic the hard-coded eth0
behaviour in the wily-and-earlier cloud images.
The work done to enable this default cloud-init behaviour (as well as
a slew of other, more complex network configuration) landed at the end
of March. Since then, we have been making changes to our build
system to support this change, and testing the output on the various
clouds on which Ubuntu images are supported.
Once we were happy that the cloud images were functioning correctly, in
the middle of last week, we made the change to cut over to the new
network interface naming. As such, cloud images will now have device
names from systemd (e.g. ens3), rather than the kernel names (e.g. eth0).
Unfortunately, we had an unrelated outage in our synchronisation
infrastructure, which meant that the images that were produced at the
end of last week didn't actually appear on cloud-images.ubuntu.com
and/or in the streams on cloud-images.ubuntu.com until yesterday.
Apologies for the late, late, late timing of this change. It was a
necessary evil to ensure that (a) we had functional cloud images for the
majority of the Xenial development cycle, but (b) we have cloud images
that we can commit to supporting for the 5 year xenial support cycle.
Thanks, on behalf of the CPC team,
Dan Watkins (Odd_Bloke)
 Thanks to Scott Moser and Ryan Harper!