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