[02:14] magicalChicken, i dont expect you to make much sense out of it [02:14] but http://paste.ubuntu.com/15443576/ [02:14] that was my quick hack attempt to do some 'fallback'. [02:14] laregely to just test some of the other assertiions i had. [02:32] magicalChicken, so one take awy of this is that the fallback network info should not try to rename devices that are 'virtual' [02:40] smoser: I think I understand it mostly. I get not trying to mess with the virtual devs === openstackgerrit_ is now known as openstackgerrit === openstackgerrit_ is now known as openstackgerrit [18:12] smoser: in the patch you shared, there was a reference to a /tmp/my.patch (looking on our shared host) it modifies the systemd networking.service Wants target; is that still needed ? [18:13] no. that is resolved with cloud-init-local saying Wants=networking-pre.target [18:13] ok [18:13] which is in my branch [18:13] net1 ? [18:13] I should pull and rebuild the deb, right ? [18:13] yeah. [18:13] let me know how it fails :) [18:14] sure [18:14] i dont think i've broken it, but i might ave [18:14] heh [18:15] i think it should work [18:15] i probably had it working with 1191 [18:15] but the working tree on taht system has this http://paste.ubuntu.com/15466159/ [18:16] so if it doesnt work, maybe read that and see if it helps [18:16] ok [18:17] \o/ [18:17] 1191 works [18:17] so happy to not see the 120 second timeout =P [18:46] rharper, but current does not ? [18:46] smoser: I just did a bzr pull, and I got 1191 [18:47] in net1 [18:47] so that's current AFAICT [18:47] maybe you have local changes not pushed to trunk.net1 ? [18:47] hm.. i have 1199 here. [18:48] I'm seeing 1199 as well [18:48] https://code.launchpad.net/~smoser/cloud-init/trunk.net1/ [18:48] It looks like it works to me, I've been working from it [18:49] oh [18:49] hrm [18:49] ah, yeah [18:49] 1199 [18:49] * rharper can't read [18:49] 1199 works fine [18:49] woot. [18:49] can you push your git that works ? [18:51] just getting that done now [18:52] smoser: ok, pushed [18:52] * rharper will now poke at using scripts.d instead of cloud-init injected scripts so we can test cloud-init disabled [18:53] magicalChicken: what are you blocked on w.r.t cloud-init-test ? [18:53] rharper: Nothing atm, since it's all passing nwo [18:53] rharper: I had been working on getting a test of cmdline ip= going but had been blocked for a bit, but I should be able to finish that now [19:07] cool [20:32] rharper, so... [20:32] y [20:32] openstack networking information -> network-yaml [20:32] that is a needed component. [20:32] should be fairly stand alone conversion [20:33] could you look at that ? [20:34] sure, do you have a pointer to their metadata yaml ? [20:42] rharper, https://review.openstack.org/#/c/85673/9/specs/juno/metadata-service-network-info.rst [20:42] is some. [20:42] i'm not sure if there is better or more complete somewhere else [20:42] cool [20:42] but that shoudl give you somethign to google for [20:43] image can have custom startup scripts to get networking config from [20:43] Config Driv [20:43] arbitrary blobs ... we don't support that in our network config as of now; what do? =) [21:00] rharper, ? [21:00] config driv ? [21:00] smoser: in the RFC [21:00] the goal was to support neutron network config, and allow arbitrary scripts run to "configure" things [21:01] cloud-init does read the config drive. [21:01] we actually do somewhat read this information [21:01] I'm just saying that if the config-drive includes scripts that muck with the network; it's possible things won't go quite right [21:02] no it doesnt [21:02] i dont think [21:02] i'm almost certain its sane [21:02] the last use-case described is what concerns me [21:02] * image can have custom startup scripts to get networking config from Config Drive [21:03] i think image here means OS image [21:03] ie, cloud-init can have custom startup scripts... [21:03] yeah, OK [21:03] to obtain the data [21:03] sorta like the per-Datasource "bring up a layer to find your source" scripts [21:03] cool [21:04] interesting. [21:04] serverstack does not populate network_data [21:04] you can get a config drive like this, rharper [21:04] nova boot --config-drive=1 --user-data=/tmp/cstack.hr20QA/ud-rendered --key-name=brickies --flavor=m1.small --nic=net-id=db6a8975-5ca2-49d6-8ca7-f8747a163e58 --image=421f67f2-c72d-4396-a678-ff4a16278fb7 xenial-20160321-210440 [21:05] --config-drive=1 is what you want [21:05] cool [21:11] going afk for 2 to 3 hours. [21:17] k [21:21] smoser: magicalChicken: well, I have run-parts based collect_scripts working now; the downside is waiting on multi.target adds like 30 seconds to the total test-time; I'll see if i can just do after cloud-init.final service and see if that speeds things up [21:26] rharper: 30 seconds isn't really all that long, so that's good [21:26] magicalChicken: yeah, not terrible; but I think it was closer to 10 seconds without; so it's mostly just empty time [21:26] yeah, I moved it to just be After=cloud-init.final [21:26] and we're at 18 seconds [21:27] cool [21:28] nice [22:13] smoser: magicalChicken: ok, pushed the run-parts collect scripts to cloud-init-test master; smoser I'll start poking on the config drive conversion to network.yaml === openstackgerrit_ is now known as openstackgerrit === openstackgerrit_ is now known as openstackgerrit