=== mgagne is now known as Guest87240
=== Guest87240 is now known as mgagne
[16:04] <mcb30> Hello!  I'm trying to debug how cloud-init handles network configuration in OpenStack.
[16:04] <mcb30> I see it correctly fetch the metadata from http://169.254.169.254/openstack/latest/network_data.json
[16:05] <mcb30> I have traced this as far as cloudinit.sources.DataSourceOpenStack.get_data()
[16:05] <mcb30> which then seems to simply throw away whatever was retrieved in results['networkdata']
[16:06] <mcb30> This fits with the fact that the log file shows "Applying network configuration from fallback ..."
[16:06] <mcb30> The end result is that cloud-init is totally ignoring whatever network configuration data is provided via the OpenStack metadata server
[16:06] <mcb30> Does anyone have any suggestions?
[16:07] <smoser> mcb30: currently cloud-init does not read network metadata from openstack datasource.
[16:07] <smoser> only from config drive.
[16:07] <smoser> we have a path forward to get there.
[16:07] <smoser> but doesnt do it right now.
[16:07] <smoser> so suggestion is "use config drive"
[16:08] <smoser> which i realize is less than wonderful.
[16:11] <mcb30> smoser: ok, thanks for saving me a few more hours of debugging :)
[16:11] <mcb30> So, is using a config drive the only way to get IPv6-enabled instances?
[16:11] <mcb30> (other than manually editing the generated ifcfg-eth0 file)
[16:17] <smoser> mcb30: yes, ant the moment.
[16:17] <smoser> its not a lot of work to make network metadata service work.
[16:17] <smoser> but just not there now
[16:32] <mcb30> smoser: can we help (either with a patch or some funding)?
[16:44] <smoser> mcb30: patches are for sure welcome.
[16:46] <smoser> and /me wishes he had a 'buy me a coffee or an ember coffee mug"
[16:54] <mcb30> Next problem (no longer a flaw in cloud-init): the network_data.json file that OpenStack creates on the config drive is missing the IPv6 configuration anyway :(
[16:54] <mcb30> The universe is determined not to let me get IPv6 working, but I shall defeat it
[16:55] <blackboxsw> word on the street mcb30 is that I'll be working on the openstack network config shortly :) (like this week)
[17:01] <mcb30> blackboxsw: awesome!
[17:02] <dpb1> I too would now like an ember coffee mug, thx smoser
[20:26] <dojordan> hey @smoser, any update on the lack of daily builds in azure? Is there someone I can follow up with about this?
[20:32] <smoser> dojordan: i'll push a bit.
[20:55] <smoser> dojordan: its in progress is all i can say.
[21:03] <blackboxsw> mcb30: if you get a chance, it'd be helpful if you have a more complex example of network_data.json that you were concerned wasn't working...    I'm working out an approach here, but wanted to make sure I handle your use case too.
[21:03] <blackboxsw> mcb30: wget http://169.254.169.254/openstack/latest/network_data.json -O - 2> /dev/null | json_pp | pastebinit    # that'd do it for me
[21:04] <blackboxsw> the initial image I'm playing with has only a single nic & ip
[21:05] <blackboxsw> but I'll be adding more simplistic examples of  multi-nic/ multi-ip vms
[21:14] <rharper> blackboxsw: I have a large collection on network_data.json examples, many of them are already encoded in the cloud-init network unittests
[21:14] <blackboxsw> oops, /me looks
[21:16] <blackboxsw> rharper: yeah my initial network_data.json doesn't really surface any ip infromation beyond DNS and # of macs
[21:16] <blackboxsw> http://paste.ubuntu.com/26497259/
[21:17] <rharper> blackboxsw: look at say tests/unittests/test_net.py
[21:17] <rharper> the OS_SAMPLES
[21:19] <blackboxsw> it really looks like we might need to query using openstack or nova client libs to get the rest of the related info if presented with limited information like my openstack/network_data.json presents
[21:20] <rharper> why do you think that?
[21:21] <rharper> there's not a lot of config, it's links (devices), networks (ip and route), and dns
[21:21] <rharper> that's all there is, the links can be physical device, or various virtual devices (bridges, bonds, etc)
[21:21] <blackboxsw> my paste doesn't contain IP info https://paste.ubuntu.com/26497259/
[21:21] <blackboxsw> or I'm being dense
[21:21] <rharper> no, it's dhcp onlly
[21:22] <rharper> look at the datasource/openstack/helpers to see how we parse that
[21:22] <rharper> blackboxsw: also you can feed network_data.json into cloud-init/tools/net-convert
[21:22] <blackboxsw> yeah, I guess I expected I'd see public IP associations that I made for the instance as well.
[21:22] <rharper> for the openstack stuff, we're already  fully working AFAIK, what we're missing is the bring-up-an-interface-to-dhcp portion
[21:23] <rharper> and then, a fetch of the network_data.json since currenlty we only invoke the helper when we find a network_data.json in the configdrive part
[21:29]  * blackboxsw also wants to persist that data in instance-data.json for openstack
[21:35] <rharper> right, so, when get_data() runs, it needs to also crawl the 'network_data.json' value and keep that in the instance-data.json
[21:35] <rharper> +1 on the idea
[21:38] <mgerdts> I just did 'make rpm; rpm -Uvh cloud-init...rpm' and rebooted.  On reboot, it really wants to get metadata from http://169.254.169.254/2009-04-04, then from another IP address (the host of my VM).  I'm having troubles finding the magic to turn that off.
[21:41] <smoser> mgerdts: well, it       is looking for a datasource. do you have one ?
[21:41] <smoser> are you running on a cloud ?
[21:41] <mgerdts> Running on SmartOS
[21:42] <mgerdts> so I'm interested in the SmartOS data source, but not the others
[21:42] <smoser> you can configure it tonlyi search the smartos datasource.
[21:42] <mgerdts> In /etc/cloud/cloud.cfg, disable-ec2-metadata is present, the same place it is on an ubuntu 14.10 VM
[21:43] <smoser> but it will only end up hitting the network when it has failed to find smartos.
[21:43] <mgerdts> ok, that could explain it.  I'm getting a stack trace when it tries to get sdc:resolvers, as that's not configured in the host.
[21:43] <smoser> at least normally... 169.254 is ec2,and the other is i suspect CloudStack.  both of which should run after smartos by default.
[21:44] <smoser> yeah. then that is the problem. hm..
[21:44] <smoser> mgerdts: can you file a bug and provide the metadata you see there ?
[21:44] <mgerdts> seems as though DNS should be an optional part of network configuration - probably missing an exception handler
[21:44] <mgerdts> sure, will do.
[21:46] <mgerdts> FWIW, I'm happy to work on this a bit.  I'm working on bringing bhyve to smartos and investigating whether cloud-init would be the easiest way to configure networking on the various other distros.  Our ubuntu images already use it.
[21:49] <blackboxsw> +1. many hands make light work
[21:57] <smoser> mgerdts: yeah, it really should be pretty easy.
[21:59] <mgerdts> https://bugs.launchpad.net/cloud-init/+bug/1746605
[21:59] <ubot5> Ubuntu bug 1746605 in cloud-init "stack trace when sdc:* not defined" [Undecided,New]
[22:01] <mgerdts> Thanks for the help smoser.  Will work up a fix and be back later.
[23:08] <blackboxsw> rharper: thx for the test tips for OS references. otherwise I would've spent all day trying to setup and reproduce different configs
[23:09] <blackboxsw> ok things looking reasonable to set this up and move the OpenStackdatasource to Local stage.
=== nacc_ is now known as nacc