[11:41] <harmw> harlowja_away: I'm looking over netutils.py again, and isn't Nova just by design skipping the network_template stuff when it's dealing with a dhcp'ed network?
[13:08] <smoser> harmw, that may well be how it works.
[13:08] <smoser> i have never succeeded in getting a template available in config drive :)
[13:08] <smoser> its definitely something that needs work.
[13:08] <harmw> yea, well
[13:08] <smoser> i really hope to fix openstack and cloud-init to do sane things
[13:08] <harmw> I hope to get a better look at things tonight
[13:10] <harmw> and that'll could very well result in a bugreport
[13:11] <harmw> not that it is a true bug, but given how it currently looks it should just do what I want - not what someone decided it 'should probably do in this or that situation'
[14:07] <glev> Hello, I have a question about fs_setup.  Does it need to be entered under the cloud configmodules section in cloud.cfg to be used in my user-data cloud-config file?
[15:03] <glev> It appears cc.disk_setup is the appropriate module, but it doesnt seem to work.  Where is this all documented?  The documentation I find shows configuration examples, but they don't work for my CentOS instance.  The log seems to not provide much useful information.
[15:14] <glev> Am I in the correct place for cloud-init project related information?
[18:38] <harmw> harlowja: ping
[18:38] <harlowja> harmw pong
[18:38] <harmw> wow
[18:38] <harlowja> ping pong
[18:38] <harmw> I which everything was so low-latency
[18:39] <gholms> Heh
[18:39] <harlowja> well u can't play ping pong at high latency
[18:39] <harlowja> it doesn't work out so well
[18:39] <harmw> true, true
[18:39] <harmw> listen, I'm checking out netinfo.py in nova
[18:39] <harlowja> kk
[18:39] <harmw> return template.render({'interfaces': nets, 'use_ipv6': ipv6_is_available})
[18:40] <harmw> that should print the template with everything substituted
[18:40] <harlowja> right
[18:40] <harmw> but it doesn't
[18:40] <harmw> it just prints the original template
[18:40] <harlowja> is there anyway u can add in a print before/after the render?
[18:40] <harlowja> and the variables to
[18:41] <harlowja> maybe this is a juno bug :-/
[18:41] <harmw> (im on icehouse)
[18:41] <harlowja> oh
[18:41] <harlowja> can u add those prints anyway
[18:41] <harmw> ofc
[18:42] <harmw> in build_template i've added print of very function (template.render())
[18:42] <harmw> which just prints out the original template
[18:42] <harmw> with the nasty literal $ signs
[18:43] <harmw> the net_info that is set on L136 contains proper values
[18:43] <harmw> eg. this works: LOG.debug("NET_INFO: eth%s %s %s %s %s", ifc_num, address, netmask, gateway, dns)
[18:43] <harmw> and this prins the original template: LOG.debug("OK, got template with contents: %s" % template.render({'interfaces': nets, 'use_ipv6': ipv6_is_available}))
[18:44] <harmw> this jinja2 stuff is way to complex for me :P
[18:45] <harmw> (btw, I hacked away 2 continue statements to make it this far)
[19:02] <harmw> nets[0]: {'broadcast': '192.168.168.255', 'netmask': '255.255.255.0', 'gateway_v6': '', 'name': 'eth0', 'dns': u'212.54.35.25', 'address': u'192.168.168.66', 'gateway': u'192.168.168.1', 'netmask_v6': None, 'address_v6': None} 
[19:02] <harmw> so thats good
[19:40] <smoser> JayF, in thinking about netowrking and cloud-init
[19:40] <smoser> and that netowkring config.
[19:40] <smoser> i think i'd like some bit of info that says "block boot on this adapter"
[19:40] <smoser> or something like that
[19:41] <JayF> that info comes from neutron atm
[19:41] <JayF> idk if there's a way to link that in, but I'd make a comment on the blueprint if you have desires
[19:41] <smoser> i'm saying the new format.
[19:41] <smoser> i realize the information comes from nuetron
[19:42] <smoser> the reason being, if cloud-init gets this info on a config drive.
[19:42] <smoser> its going to configure networking. 
[19:42] <smoser> but then it should not let user code run until sane bits of netwoork are up.
[19:42] <smoser> hm..
[19:42] <JayF> who is to decide what is a sane amount of network?
[19:43] <JayF> I'm always careful about that
[19:43] <smoser> right.
[19:43] <JayF> bceause in our cloud, at least, you can spin up boxes in 100% private networks
[19:43] <smoser> its non-trivial
[19:43] <JayF> so we can't depend on things for the general case that require internet to exist
[19:43] <smoser> so heres the thing i was thinking about.
[19:43] <smoser> system boots. reads some network from config drive.
[19:43] <smoser> user hotplugs network device
[19:44] <smoser> cloud-init reads config from MD server for that device and configures it.
[19:44] <smoser> should cloud-init block the next boot on presense of that device ?
[19:45] <JayF> I don't know about that specific scenario
[19:45] <JayF> but I'd say cloud-init should do as much as it can regardless of some failures
[19:45] <JayF> (and then give me a way as a developer to instead have it throw a hissy fit, aka exception, if something breaks)
[19:45] <smoser> theres a difference between failure
[19:45] <smoser> and "hasnt hotplugged yet"
[19:45] <JayF> Ah
[19:46] <smoser> and no real way to know the difference
[19:46] <JayF> Yeah, IDK about those cases
[19:46] <JayF> because I don't hotplug things :)
[19:46] <JayF> atm at least
[19:46] <smoser> right. 
[19:46] <smoser> so vm, neutron hotplug the thing.
[19:46] <smoser> on reboot, i dont know if i should expect that nic or not.
[19:47] <smoser> and dont know if i've missed an event that would have pulled it from my config.
[19:47] <smoser> ie, missed the hotplug remove during the reboot.
[19:47] <JayF> this is why in the model I proposed for event-driven changes
[19:47] <JayF> that you just pass the event and the updated data and say "make it right"
[19:47] <JayF> you can't manage this as a certain number of steps to perform in order every time imo
[19:48] <JayF> you have to just take the data you're given and do a thing with it, and if, for instance, that data references a network drive that the hypervisor didn't hook up, or that the OS image didn't wait to be ready before cloud-init runs
[19:48] <JayF> then that can't be a cloud-init problem, it's an environmental problem
[19:48] <smoser> hm.
[19:49] <smoser> thats a good point. 
[19:49] <smoser> but then makes the data on config-drive possibly stale.
[19:50] <JayF> yes
[19:50] <smoser> and at that point in boot, before a network is available to the MD thats all i have.
[19:50] <JayF> I mean, should we support a mix of sources generally? Do we?
[19:50] <JayF> ooooooooh.
[19:50] <smoser> so if data on config drive had 'required' or not.
[19:50] <smoser> then i could block until all required.
[19:50] <smoser> and just "never unplug stuff that is required" rule.
[19:51] <smoser> and then once required are up i can hit MD and get updated info
[19:51] <JayF> Yeah I'm not sure I have a good informed opinion on this, and I have other stuff I need to finish this week, but I'm going to let that bake for a while and think about it
[19:51] <smoser> :)
[19:52] <smoser> this was bout all the time i could spend on this now too
[19:52] <smoser> i'll comment in gerrit
[20:07] <harlowja> harmw so it seems like the template is getting populated then right?
[20:08] <harmw> it's beeing read just fine, but nothing gets replaced inside... so the original template is copied with any specifics in to the configdrive
[20:09] <harlowja> ya, thats totally weird
[20:09] <harmw> what else is new :P
[20:09] <harlowja> is it possible to open a nova bug for this, it seems like someting is wrong ;)
[20:09] <harlowja> although i'm not sure why y! hasn't seen it since we run that code 
[20:09] <harlowja> and are running icehouse
[20:10] <harlowja> so that part doesn't quite make sense, ha
[20:10] <harmw> haha
[20:11] <harmw> template.render(nets[0])
[20:11] <harmw> that still produces the original template :|
[20:11] <harmw> I don't get it
[20:11] <harlowja> that should run via https://github.com/openstack/nova/blob/stable/icehouse/nova/virt/netutils.py#L150 right?
[20:12]  * JayF suspects requirements differences
[20:12] <harmw> yup
[20:12] <harmw> JayF: I'm growing a feeling in that direction as well
[20:12] <harlowja> but jinja2 not processing variables would be like a bad bug, ha
[20:12] <harlowja> or not processing in the same manner, lol
[20:12] <harmw> indeed, so I'm doubting my own setup as well :p
[20:13] <harlowja> can u dump 'nets' and such, then try to load the template in a smaller script that uses your own code, try to replace nets in that code instead?
[20:13] <harlowja> just to cause the same failure
[20:14] <harmw> already trying something like that
[20:14] <harlowja> hmmm, and your template is https://github.com/openstack/nova/blob/stable/icehouse/nova/virt/interfaces.template right?
[20:14] <harmw> oh my
[20:14] <harmw> no
[20:14] <harmw> nowhere near
[20:14] <harlowja> hmmm
[20:14] <harlowja> that might be it
[20:15] <harmw> uhu
[20:15] <harlowja> it seems https://github.com/openstack/nova/commit/fa0d61084e50 changed cheetah -> jinja2
[20:15] <harmw> I'm reading the vars in the template should be {{ bla }} as well
[20:15] <harlowja> did RDO forget to pickup that file :-/
[20:15] <harmw> which is merely a $bla in my template
[20:15] <harlowja> ya, thats cheetah syntax :(
[20:15] <harmw> ah!
[20:15] <harlowja> so ya, that would be an issue ;)
[20:16] <harlowja> u used RDO?
[20:16] <harmw> ofcourse
[20:16] <harmw> centos6 + rdo icehouse
[20:16] <harlowja> ah, ya, rdo packagign bug i think
[20:16] <harlowja> wonder if thats been reported
[20:16] <harmw> # rpm -qf /usr/share/nova/interfaces.template 
[20:16] <harmw> openstack-nova-common-2014.1.2-1.el6.noarch
[20:17] <harmw> though thats the old file
[20:17] <harlowja> ya, i bet they forgot to update it or something
[20:17] <harlowja> *they being RH
[20:17] <harmw> uhu
[20:17] <harmw> you know where their bugzilla is at?
[20:17] <harlowja> not sure, ha
[20:17] <harmw> h
[20:17] <harmw> bugzilla.rh
[20:18] <harlowja> something like that
[20:18] <harlowja> u can poke 'dprince_' in #openstack-dev
[20:18] <harlowja> he might be able to get that to occur quicker
[20:18] <harlowja> afaik he knows the people that know the people
[20:18] <harmw> ah ok
[20:18] <harlowja> *and also works @ RH
[20:18] <harmw> hhe
[20:18] <harmw> openstack-dev, guess I should join that channel as well then
[20:19] <harlowja> ya, openstack has tons of channels, lol
[20:19] <harmw> my irssi is getting a bit crowded
[20:19] <harlowja> :)
[20:20] <harmw> does he share your TZ?
[20:22] <harlowja> harmw i think EST us
[20:22] <harlowja> so not mine (PST)
[20:30] <harmw> ok, well added a bug
[20:35] <harmw> hhee, well that apparently did the trick - I changed the template to be jinja2
[20:36] <harmw> so I now have a configdrive with proper network file, woohoo
[20:47] <harmw> hm, well, this *almost* works 
[20:48] <harmw> nova just told my vm something about eth0... and freebsd only knows of vtnet0
[20:48] <harmw> so thats something to look into in freebsd.py
[20:49] <harmw> but other than that, configdrive works and even configured the network (eventhough it was the wrong interface)
[20:49] <harmw> and now it's bedtime :)
[21:02] <harlowja> harmw coolness