[05:23] Hello all. I'm having some problems turning on debugging info for cloud-init on an instance in EC2. Is it as simple as having "verbose:\n debug: true" in the cloud-init config? [05:25] I'm getting the following two lines of output in my cloud-init-output.log file with that config present, and I see the following two lines ... not sure what is happening between those two steps that causes it to take 2 minutes [05:25] Cloud-init v. 0.7.5 running 'modules:config' at Mon, 23 May 2016 05:02:58 +0000. Up 35.99 seconds. Cloud-init v. 0.7.5 running 'modules:final' at Mon, 23 May 2016 05:05:08 +0000. Up 166.10 seconds. [05:26] For context, I'm using Ubuntu 14.04 and I'm running v0.7.5 of cloud-init (is this ancient?) [15:03] smoser: Hi, I extended the MP at https://code.launchpad.net/~paelzer/cloud-init/test-apt-source/+merge/294521 [15:04] it has now the dictionary based handling and all kind of tests around it [15:04] smoser: I'll check tomorrow if I need to revise it a lot / a bit / not - and will start to poke at the curtin portion of it then [15:05] smoser: I'll expect to have some questions tomorrow when you come online, but will let you know then [17:25] rharper ya that's def where the complexity comes from ;) [17:25] and/or figuring out sysconfig for myself, and its weirdness :-P [17:27] harlowja: hehe [17:27] rharper although i think https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7/ is mostly there, just eyes on that would be cool [17:27] let me know if it looks dumb :-P [17:27] https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7/#file-sysconfig-py-L320 is the main stuffs [17:28] oddly i don't think redhat has a way to configure routes without an interface [17:28] or at least i'm not sure if there is one [17:31] harlowja: I gave it a once over the other day; it looks quite reasonable (cleaner than my initial cut); looking to steal a lot of that; we may find with the two implementations (and a networkd coming) that we have a base set of hooks that new config backends would implement [17:31] cool [17:33] the networkd does change things up quite a bit as there is no single file to write, rather multiple files (.link for name mapping) (.network for networks which may or maynot be device specific) and (.netdev for virtual devices like bridges and bonds); so the in-order processing that happens for eni and sysconfig don't have to apply but certainly can. [17:34] ya, sysconfig also doesn't have single files [17:34] only eni i think has a single file [17:35] ok [17:35] bbiab [17:46] smoser rharper can we (or shall i?) merge in https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor [17:46] that way this sysconfig stuff (which that uses as a base) ; can start to get reviewed more offically :-P [17:47] * harlowja doesn't know to well how to stack things in bzr (against a branch that hasn't merged yet) [17:51] harlowja, can you write at very least a combined commit message and description there ? [17:51] is it all just "refactor" did you clean up the N different internal states ? [17:51] sure boss [17:51] ummm, let me check [17:51] mostly refactor :-P === nacc_ is now known as nacc [21:05] ok, updated https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 rharper if u want to see [21:09] looking [21:14] harlowja: nice, lines 34 -> 70ish look like cloudinit.net common stuff that all backends could use [21:15] def [21:24] harlowja: nit: L82 in the header you say on %(now)s ; would 'at' or '@' be more natural ? L324 render_dns; you have it as a pass, but I'd think the signature would need to take a list object to append something if/when it ever did support updating dns; [21:24] sure [21:24] rharper yup yup, dns not done yet ;) [21:26] let me get that in a more offical place, ha [21:31] ok smoser added nice handy commit message in https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 :-P [21:32] and at the risk of exposing my ignorance; a few of the render methods are @classmethod ; but it doesn't appear that they're used outside of other methods within the class; what's that doing ? [21:32] ya, more or less just a thing i've gotten used to, no need to pass self around if not using it for those [21:33] and if don't need any class attributes, then just doing staticmethod [21:33] can make them all instance methods, but got in the habit of not doing that and using the right decorator [21:33] I see, you didn't explicitly need to reference anything in the instance s? [21:33] nah [21:34] gotcha [21:34] w.r.t quoting, my reading on ConfigParser and INI is that no quoting should be needed; anything after the Variable= is included in the value ... [21:34] hmmmm, i thought most of these sysconfig files were just 'sourced' into scripts [21:35] oh [21:35] hehe [21:35] I forgot [21:35] the bash scripts [21:35] you're right for sysconfig [21:36] ya, i didn't think sysconfig stuff was very smart, lol [21:36] and it all eventually gets parsed by some shell scripts, lol [21:37] so without doing quoting things go bad (especially with whitespace) [21:38] ie like https://gist.github.com/harlowja/5f9b3008d20d2668e8bcfc28eb491955#file-gistfile1-txt-L102 [21:39] why it was done like this, who knows [21:40] yeah [21:40] I was just confused [21:40] sysconfig is huge legacy [21:40] def [21:41] at the same time, the guts of ifupdown are ... harder to read than the in-line awk in sysconfig so no leg to stand on there [21:45] lol [21:46] ya, it's all one big mess imho [21:46] guess thats why systemd :-P [21:51] one mess + second mess => systemd ? not sure what we expect then [21:51] magic ? [21:51] :) [21:51] * rharper sprinkles some systemd magic around [21:51] I do know that we'll now be told there _is_ one TRUE way [21:51] whether that's right or not; at least you have an answer [21:51] ha [21:51] ya [22:10] mgagne if u get a chance can u look over https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 [22:10] its my creation, based off in part https://raw.githubusercontent.com/mgagne/cloud-init-fedora-pkg/epel7/cloud-init-0.7.5-network-info-support.patch + the refactored stuffs [22:10] pretty sure its right, and u can just feed it a openstack json file and see what is output [22:10] $ python sysconfig.py test.json [22:10] for example [22:22] harlowja: neat, I'll look too. [22:22] thx [22:22] https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7#file-sysconfig-py-L406 == the main function that thinks get started from [22:26] harlowja: just to be sure, what version of cloud init am I supposed to be running ? [22:27] a unmerged branch ;) [22:27] (for the imports) [22:27] ehhh, how do I set that up ? [22:27] https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 [22:27] that one [22:28] can you zip it somewhere or something ? Afraid my bzr skills are pretty awesome (not) [22:28] sure [22:29] dmsimard actually u should just be able to run [22:29] bzr branch lp:~harlowja/cloud-init/cloud-init-net-refactor cloud-init [22:29] that will get u the branch [22:30] (into a folder called 'cloud-init') [22:30] ok [22:30] let me see.. [22:31] * dmsimard installs bzr ... and shivers [22:32] lol [22:33] try a few json files (from openstack); let me know if anything looks really crazy (it might be crazy) [22:34] since things like https://git.fedorahosted.org/cgit/initscripts.git/plain/sysconfig/network-scripts/ifup-eth are crazy [22:34] harlowja: it's not crazy, it's empty :) [22:34] sec [22:34] lol [22:34] k [22:35] running stuff like $ python sysconfig.py test.json will just output to stdout btw [22:35] it doesn't write anywhere yet [22:35] harlowja: https://gist.github.com/dmsimard/d6eaa8b61f3c601d833b29ef430637da this is what I'm testing against [22:35] k let me try [22:35] and this is my output: http://paste.openstack.org/show/498378/ [22:36] yup, looks like that to me also, ha [22:36] ok, let me see where things went here [22:36] I have the full config drive if you want, it may or may not be the one I think I may have provided you last time [22:36] oh i know [22:37] let me see, def seems like it should have more :-P [22:37] one of these other format layers killing the interfaces there [22:37] will figure that out [22:38] fwiw that's a mitaka config drive, if it's different or anything, no clue [22:38] k [22:39] u can try the example in https://bugs.launchpad.net/nova/+bug/1514082 [22:39] i was trying that one also [22:39] as i figure out which layer dropped the info in your file [22:40] harlowja: ah, yup, that one works fine [22:41] harlowja: the whole config drive is @ https://dmsimard.com/disk.config if you want to peek at it. [22:41] np, not needed i think, just that one file is what matters here [22:43] you should add my network_data.json to your unit tests in test_network_config_conversions after you figure it out :) [22:43] ya [22:44] ya, ok, sooo might have to poke rharper on this one [22:45] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L239 is puking on your date [22:45] primarily because http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L266 keys don't exist [22:46] and in the openstack version, they aren't getting translated ... [22:46] I updated my gist to be pretty printed :p https://gist.github.com/dmsimard/d6eaa8b61f3c601d833b29ef430637da [22:46] and i'm not quite sure what they should translate to/from [22:46] it seems like that code is looking for bridge_interfaces and then interfaces (two sets of interfaces) [22:46] where your example only has one :-P [22:46] so what does it bridge to :-P [22:47] it's a vm on a linuxbridge environment [22:47] right [22:47] the vm doesn't have to configure any bridge [22:47] it's done on the compute node [22:48] sure [22:48] but from my understanding of that code, its looking for a interface definitions of what to bridge to what else [22:49] so i'm not sure the mapping of http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L239 and what openstack provides (is data missing?) [22:50] what happens is that your json file first goes into a intermediarty format that is '[{'subnets': [{u'routes': [{u'netmask': u'0.0.0.0', u'network': u'0.0.0.0', u'gateway': u'172.19.3.254'}], u'netmask': u'255.255.252.0', u'type': 'static', 'ipv4': True, 'address': u'172.19.1.34'}], 'name': u'tap1a81968a-79', 'mac_address': u'fa:16:3e:ed:9a:59', u'type': 'bridge', 'mtu': None}, {u'type': 'nameserver', u'address': u'172.19.0.12'}]' [22:50] So you have a network_data.json that's linuxbridge (mine) and the one you provided from the bug is from an ovs setup. It's a pretty good test to ensure both work well. [22:50] The OVS one you linked also has the notion of links [22:51] which then gets processed by that code into another intermediary format and then that format is what the sysconfig.py stuff works on [22:51] right, something is off/missing in the handle_bridge stuff here [22:51] The links are probably just interfaces on the compute node (bridge tap) and the networks are bridged to these links on the compute node [22:53] ya, i'm gonna delegate to rharper on this one, unsure what the expected openstack translation is for that to correctly work === natorious_ is now known as natorious [22:53] I'm off for the day, let me know if you find out and I'll poke at it some more .. I could even pitch a few VMs at it with the real thing :) [22:54] ya, eventually we'll get there ;)