OpenStack datasource does not read network data

Bug #1749717 reported by Jorge
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

I'm using Openstack on Mitaka version. My projects use prefix delegation to get IPv6 configuration and a common IPv4 DHCP. IPv4 addresses and configurations are working well. But for IPv6 my instances just get the address, probably via RA of neutron. I'm looking for a way to get other informations like that on dhcpv6 (name servers, for example).

My subnet configuration is --ipv6_ra_mode dhcpv6-stateless --ipv6_address_mode dhcpv6-stateless. I'm using Ubuntu Cloud Image 16.04 LTS.

Addresses are well generated and VMs have connectivity. But, dhcpv6 requests are not sent. We need that VMs request other information (like nameservers) from dhcpv6 on boot. I've tested manually after boot and it works.

I've seen that the file /etc/network/interfaces.d/50-cloud-init.cfg is generated at boot time. Its content is:

# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto ens3
iface ens3 inet dhcp

To do what I'm thinking I just need to put these other lines in this configuration file:

iface ens3 inet6 auto
  pre-up sleep 5
  dhcp 1

This was tested, running dhcpv6 manually. Sleep 5 is due a Ubuntu bug and 'dhcp 1' indicates that information should be obtained from dhcpv6 server.

Is there some way to do cloud-init read that the subnet is configured as dhcpv6 and then generate a configuration file as that? It's just necessary that cloud-init launch the dhcpv6 client.

Thank you!

Related branches

Revision history for this message
Jorge (correajl) wrote :
Revision history for this message
Scott Moser (smoser) wrote :

I modified the subject of this bug.

Openstack provides network configuration data in its metadata service

currently, cloud-init reads that data, but does not use it in the
openstack metadata datasource.

We would like to make cloud-init able to read this data and apply
the configuration at first boot. There is a fairly straight forward
path to doing this, but it just is not done yet.

At this point, then the options you have to make it "just work" is
to use the config drive datasource in openstack. That provides the
same network_data.json but is read earlier in cloud-init so that
it affects the network configuration of the system.

Changed in cloud-init:
status: New → Confirmed
importance: Undecided → Medium
summary: - A way to configure dhcpv6 client
+ OpenStack datasource does not read network data
Revision history for this message
Chad Smith (chad.smith) wrote :

An upstream commit landed for this bug.

To view that commit see the following URL:

Changed in cloud-init:
status: Confirmed → Fix Committed
Revision history for this message
Scott Moser (smoser) wrote : Fixed in cloud-init version 18.3.

This bug is believed to be fixed in cloud-init in version 18.3. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
Revision history for this message
Yang Youseok (ileixe) wrote :


We encounter Openstack VM has static configuration from this commit and it makes routing problem with our cluster. (Because we had a custom DHCP agent which does not offer assigned network mask in neutron side). It seems to be implemented that what should be done before though, it definitely broke the previous workflow.

So is there no way to change the default flag 'apply_network_config=False' for backward compatibility?

Revision history for this message
Yang Youseok (ileixe) wrote :

Last sentence looks confusing.

I mean what about changing default flag 'apply_network_config=False' from 'apply_network_config=True' which is default value.

Revision history for this message
James Falcon (falcojr) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.