cloud-init does not use interfaces.d in trusty
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
High
|
Unassigned | ||
cloud-init (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Hi,
Reference/context: https:/
The trusty image provided by http://
When I boot this image in an Openstack non-dhcp networking environment, cloud-init configures the static IP provided by Neutron directly in /etc/network/
This means I now have two eth0 devices configured, in two different files.
Booting 20 VMs with the same image yields around 50-60% of VMs that are not reachable by network.
Soft rebooting a VM in this state or doing and "ifdown eth0 && ifup eth0" will make it ping.
I removed the the eth0 interface file in /etc/network/
Now, I see three possible outcomes:
- If eth0 is present in /etc/network/
- If eth0 is present in /etc/network/
- Ubuntu cloud images ships without eth0 being configured by default
description: | updated |
Changed in cloud-init: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in cloud-init (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → High |
Your 'ask' comment at /ask.openstack. org/en/ question/ 28297/cloud- init-nonet- waiting- and-fails/
https:/
/etc/network/ interfaces shows:
# Injected by Nova on instance boot
If that entry was "injected" by nova, then there really isnt much or anything cloud-init can do about this.
This is a good example about why host "injection" is inherently flawed. The right fix for your problem is then to have nova realize that 'eth0' already existed, and remove /etc/interfaces.d/. That is clearly brittle and requires updating your hypervisor/cloud which is quite unreasonable.
if cloud-init reads network-interfaces from config drive, then it should handle eth0 correctl (ie, we need to fix that).