=== cpaelzer_ is now known as cpaelzer === sterfield_ is now known as sterfield [14:27] bah. [14:27] rharper, http://people.canonical.com/~rharper/curtin/topics/networking.html [14:27] can routes be per-interface ? [14:27] yes [14:28] they are in cloud-init; I've a branch to bring curtin in-line [14:29] it was needed to support the routes from network_data.json [14:36] smoser: http://paste.ubuntu.com/17644428/ (that's an network_config with routes per subnet) [14:37] rharper, i think they bot lost in cloud-init [14:37] :-( [14:49] hrm [14:49] I don't think so [14:50] smoser: cloudinit/net/eni.py:Renderer:_render_route [14:51] it's possible the logic got broken in the refactor ; I don't think we have a unittest specifically for the routes under a subnet [14:58] rharper, yeah, i think it got busted. [14:58] * rharper shakes fist at harlowja [14:58] note the coede does [14:58] for route in subnet.get('routes', []): [14:59] but then later [14:59] for route in network_state.iter_routes(): [14:59] smoser: shall I fix it? or do we make harlowja do that ? [14:59] well, i'm close to having it and some other cleanups [15:00] in bzr+ssh://bazaar.launchpad.net/~smoser/cloud-init/trunk.net-improve-lo-dns/ [15:00] ok [15:00] i'm not sure exactly how to get the per-iface routes though [15:01] in the new fancy net refactor world... I need to look at that [15:02] smoser: hrm, yeah I don't think that iter is actually what we'd need [15:02] the routes in subnets were part of the subnet under the iface property [15:02] so you really want to iface_iter [15:02] and then get subnets under the iface [15:03] iter_interfaces [15:05] smoser: hrm, it looks ok from here... in _render_interfaces, we have the for iface in iter_interfaces, and then we have a for route in subnet.get('routes', []); that'll render per-interface routes; the outer iter_route is for the global routes (type: route) [15:06] but i dont hitnk subnet.get('routes', []) ever returns anything but [] [15:12] ok. seems i was wrong. [15:12] rharper, ^ [15:12] but in your http://people.canonical.com/~rharper/curtin/topics/networking.html [15:13] it says gateway is CIDR netmask notation [15:13] whichi 'dbut it seems it needs a netmask. [15:13] that's a copy/paste error, thanks [15:14] the gateway itself doesn't take cidr, but it can be address with cidr, or address + netmask key [15:15] and I've not updated the curtin docs on routes per interface yet since we haven't merged in that code yet; I have a branch but decided to wait until we moved cloud-init networking to the refactor; after this branch of ours, I can rebase curtin net on this stuff. [15:30] rharper, https://code.launchpad.net/~smoser/cloud-init/trunk.net-improve-lo-dns/+merge/298035 [15:32] smoser: reading [15:34] rharper, this is where we need an equality test for *something* . whether that be network config or network state or ENI. [15:34] its hard to test that what was rendered is right. [15:35] there are two steps [15:35] 1) cmp(expected_output, input -> output ) [15:36] 2) validate expected_output achieves what it says (run eni in a guest) [15:36] Hi! i'm having some problems with execution order on a multipart config. Please here are the details... http://serverfault.com/questions/785344/how-to-execute-some-commands-before-the-user-scripts-in-cloud-init [15:37] thanks [15:37] we don;'t have a "vmtest" in cloud-init yet; the cloud-init-tests repo is the closest we have, which would look at the input (and render it to state or yaml) we inspect an instance after cloud-init runs and extract network config and compare that to the input [15:43] blackjid, look in /var/lib/cloud/instance/scripts/ [15:43] you'll see one file named 'runcmd' [15:43] and the other files that are in your multipart are named by their filename [15:44] the scripts in that directory are run in C locale sorted order (as if by runparts) [15:44] so if you change the name of the script you've added from [15:44] filename="00-rancher_server_install" [15:44] to [15:44] filename="zz-rancher_server_install" [15:44] then yo'ull be good. [15:45] rharper, yes. thats surely one way. but if i have a parser of ENI, then i should be able to render an ENI and then parse it back into network config. [15:46] and then compare that network config to the one i started with. [15:47] thanks smoser!, I'll try! that.. I thought they were run in sorted order, that's why I added the 00- but I don't quiet understand why is the other way around... [15:47] smoser: that's step 1, but without someone putting fixed input into the expected output; I worry that if we're generating both sides, something can get missed [15:49] blackjid, http://paste.ubuntu.com/17647782/ [15:50] blackjid, if i had it to do again, i might make runcmd be in a file called '50-runcmd' to be more fitting. but its not easily changed at this point [15:53] thanks again smoser!, it worked perfectly!... [16:06] and generally speaking the ability to compare two network configs for equality without booting a system is fairly desireable. [16:12] smoser: sure; but declaring them equal without checking if they do anything isn't super valuable, we need both. and I argue that we we'll want both the round-trip eni -> config -> eni ; as well as hand-crafted eni vs. generated eni as a check on parser bugs === dmsimard is now known as dmsimard|afk [17:15] rharper smoser what did i break, lol [17:15] that code needs more tests :-P [17:19] harlowja, it does indeed [17:19] and i dont think you actually broke anything though [17:26] ah, woot [17:26] i never break anything [17:26] obviously [17:26] lol [17:49] harlowja, https://code.launchpad.net/~smoser/cloud-init/trunk.net-improve-lo-dns/+merge/298035 if you want to read that, htat'd be nice. [17:49] kk [17:49] got a internal review, then that one [17:49] then some openstack ones [17:49] guess today is review day [17:49] lol === dmsimard|afk is now known as dmsimard