cloud-init

OpenStack datasource does not read network data

Bug #1749717 reported by Jorge on 2018-02-15

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	cloud-init	Fix Released	Medium	Unassigned

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!

Tags:

Related branches

~chad.smith/cloud-init:ubuntu/devel

Merged into cloud-init:ubuntu/devel at revision af157b0381406efbd389ea952952e92358638797

Server Team CI bot: Approve (continuous-integration) on 2018-05-23

Scott Moser: Pending requested 2018-05-23

Diff: 4627 lines (+1811/-744)

57 files modified

cloudinit/cmd/main.py (+1/-1)
cloudinit/config/cc_mounts.py (+44/-29)
cloudinit/config/cc_phone_home.py (+4/-3)
cloudinit/config/schema.py (+46/-18)
cloudinit/ec2_utils.py (+6/-8)
cloudinit/sources/DataSourceAzure.py (+47/-16)
cloudinit/sources/DataSourceCloudStack.py (+10/-21)
cloudinit/sources/DataSourceConfigDrive.py (+2/-2)
cloudinit/sources/DataSourceEc2.py (+15/-33)
cloudinit/sources/DataSourceMAAS.py (+1/-1)
cloudinit/sources/DataSourceOpenStack.py (+105/-56)
cloudinit/sources/DataSourceSmartOS.py (+6/-7)
cloudinit/sources/__init__.py (+76/-0)
cloudinit/sources/helpers/azure.py (+3/-2)
cloudinit/sources/tests/test_init.py (+87/-2)
cloudinit/tests/helpers.py (+10/-2)
cloudinit/tests/test_url_helper.py (+27/-1)
cloudinit/tests/test_version.py (+17/-0)
cloudinit/url_helper.py (+28/-1)
cloudinit/user_data.py (+3/-3)
cloudinit/util.py (+21/-37)
cloudinit/version.py (+4/-0)
debian/changelog (+28/-0)
packages/brpm (+3/-3)
packages/debian/rules.in (+2/-0)
packages/redhat/cloud-init.spec.in (+7/-0)
packages/suse/cloud-init.spec.in (+7/-0)
systemd/cloud-config.service.tmpl (+1/-0)
tests/cloud_tests/collect.py (+1/-1)
tests/cloud_tests/platforms/instances.py (+29/-10)
tests/cloud_tests/platforms/lxd/instance.py (+1/-1)
tests/cloud_tests/releases.yaml (+16/-0)
tests/unittests/test__init__.py (+4/-4)
tests/unittests/test_data.py (+11/-2)
tests/unittests/test_datasource/test_aliyun.py (+0/-2)
tests/unittests/test_datasource/test_azure.py (+88/-17)
tests/unittests/test_datasource/test_azure_helper.py (+1/-1)
tests/unittests/test_datasource/test_common.py (+1/-0)
tests/unittests/test_datasource/test_ec2.py (+0/-12)
tests/unittests/test_datasource/test_gce.py (+0/-1)
tests/unittests/test_datasource/test_openstack.py (+115/-16)
tests/unittests/test_datasource/test_scaleway.py (+0/-3)
tests/unittests/test_ds_identify.py (+70/-4)
tests/unittests/test_ec2_util.py (+0/-9)
tests/unittests/test_handler/test_handler_apt_conf_v1.py (+6/-10)
tests/unittests/test_handler/test_handler_apt_configure_sources_list_v1.py (+0/-7)
tests/unittests/test_handler/test_handler_apt_source_v1.py (+10/-17)
tests/unittests/test_handler/test_handler_apt_source_v3.py (+10/-17)
tests/unittests/test_handler/test_handler_chef.py (+12/-4)
tests/unittests/test_handler/test_handler_mounts.py (+100/-4)
tests/unittests/test_handler/test_handler_ntp.py (+21/-30)
tests/unittests/test_handler/test_schema.py (+33/-6)
tests/unittests/test_util.py (+27/-3)
tools/ds-identify (+18/-5)
tools/read-dependencies (+6/-2)
tools/run-centos (+30/-310)
tools/run-container (+590/-0)

~chad.smith/cloud-init:feature/os-local

Merged into cloud-init:master at revision cd1de5f47ab6b82f2c6fd61a5f6681f33b3e5705

Server Team CI bot: Approve (continuous-integration) on 2018-05-23

Scott Moser: Approve on 2018-05-23

Revision history for this message

Jorge (correajl) wrote on 2018-02-15:

cloud-init.tar Edit (270.0 KiB, application/x-tar)

Revision history for this message

Scott Moser (smoser) wrote on 2018-03-08:

Hi,
I modified the subject of this bug.

Openstack provides network configuration data in its metadata service
http://169.254.169.254/openstack/latest/network_data.json

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 on 2018-05-23:

An upstream commit landed for this bug.

To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=cd1de5f4

Changed in cloud-init:
status:	Confirmed → Fix Committed

Revision history for this message

Scott Moser (smoser) wrote on 2018-06-20: 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 on 2019-06-20:

Hi,

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 on 2019-06-20:

Last sentence looks confusing.

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