| === mgagne is now known as Guest87240 | ||
| === Guest87240 is now known as mgagne | ||
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| smoser | which i realize is less than wonderful. | 16:08 |
| 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:11 |
| 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:17 |
| mcb30 | smoser: can we help (either with a patch or some funding)? | 16:32 |
| smoser | mcb30: patches are for sure welcome. | 16:44 |
| smoser | and /me wishes he had a 'buy me a coffee or an ember coffee mug" | 16:46 |
| 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:54 |
| blackboxsw | word on the street mcb30 is that I'll be working on the openstack network config shortly :) (like this week) | 16:55 |
| mcb30 | blackboxsw: awesome! | 17:01 |
| dpb1 | I too would now like an ember coffee mug, thx smoser | 17:02 |
| dojordan | hey @smoser, any update on the lack of daily builds in azure? Is there someone I can follow up with about this? | 20:26 |
| smoser | dojordan: i'll push a bit. | 20:32 |
| smoser | dojordan: its in progress is all i can say. | 20:55 |
| 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:03 |
| blackboxsw | the initial image I'm playing with has only a single nic & ip | 21:04 |
| blackboxsw | but I'll be adding more simplistic examples of multi-nic/ multi-ip vms | 21:05 |
| 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:14 |
| 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:16 |
| rharper | blackboxsw: look at say tests/unittests/test_net.py | 21:17 |
| rharper | the OS_SAMPLES | 21:17 |
| 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:19 |
| rharper | why do you think that? | 21:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| * blackboxsw also wants to persist that data in instance-data.json for openstack | 21:29 | |
| 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:35 |
| 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:38 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| blackboxsw | +1. many hands make light work | 21:49 |
| smoser | mgerdts: yeah, it really should be pretty easy. | 21:57 |
| 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] | 21:59 |
| mgerdts | Thanks for the help smoser. Will work up a fix and be back later. | 22:01 |
| 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:08 |
| blackboxsw | ok things looking reasonable to set this up and move the OpenStackdatasource to Local stage. | 23:09 |
| === nacc_ is now known as nacc | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!