=== rangerpbzzzz is now known as rangerpb === nacc_ is now known as nacc [17:22] i've worked around https://bugs.launchpad.net/cloud-init/+bug/1671927, but now the gateway is not being rendered to ifcfg-eth0. gateway is defined in network_data.json, but not content/0000, so more evidence i guess that it's preferring 0000 in this case === mgagne_ is now known as mgagne [18:17] dtp, can you give the config drive that you ave? [18:17] smoser some of the files are available at http://imgur.com/a/qEElh [18:18] and others are attached to the bug. or is there another you need? [18:18] dtp, you couldnt use pastebin ? for text :) [18:19] i don't have net access to the VM / only have spice console [18:19] dtp, so the issue... is that cloud-init did not write that /etc/network/interfaces [18:19] as it says, nova "injected" it. [18:19] essentially, your cloud platform broke your image by thinking it knows what it is doing. [18:19] and cloud-init does not attempt to un-break it for that scenario. [18:20] that make sense ? [18:20] which /etc/network/interfaces? [18:20] i'm 95% certain that nova mounted the image and write /etc/network/interfaces [18:20] oh wait. [18:20] no. [18:20] ok. let me re-think [18:20] this is fedora 25 / no /etc/network/interfaces, only network-scripts/... files [18:20] right [18:21] so where i'm coming from is this all worked on fedora 23 w/ older cloud-init [18:21] trying to get fedora 25 up [18:22] you're right. it sure would appear that cloud-init is preferring to parse the 0000 file [18:22] theres no way you can get the disk there? [18:23] which file do you need? [18:23] you shoudl be able to bring up networking by hand [18:23] if you just get me the config drive (dd if=/dev/vdb of=my.img) [18:23] or something to that affect, thats the easiest. [18:23] ok, i'm in a meeting but will after === shardy is now known as shardy_afk [19:10] dtp, just reading code, it sure seems like it should be looking at the network json in 0.7.8 [19:11] some of the other guys in here on Friday seemed to think it was skipping that stuff and using meta data or something? [19:12] well if you attached a config drive then it should be reading that. [19:12] there is a config drive, right ? [19:12] thats what you showed with 'cat' ? [19:12] yeah [19:13] yeah [19:13] they were saying something else in the config drive caused it to ignore network_data.json [19:13] meta_data i think [19:13] but i didn't see much in there [19:15] hm. [19:15] can you show me ls /sr0/openstack/ ? [19:17] smoser - http://imgur.com/a/YXfc5 - still working on bringing network up [19:19] hm. [19:19] that wasnt what i expected :) [19:19] oh? [19:20] that should work. i expected that you were going to honly have 2016-10-06 and 2017-02-22 [19:20] one thing we noticed was that the debug logs in ConfigDrive where it says (if network_data use it, else use 0000) weren't being logged [19:21] so it wasn't making it there before it went to write net conf [19:21] i guess the trace is in that original imgur [19:22] would explain how it skipped that part [19:22] well, if you can get me a copy of the cdrom i can get further. without that, ... i'm not sure whats going on. and /var/log/cloud-init.log woudl be good too [19:22] yeah, that's in the imgur already - http://imgur.com/a/qEElh [19:22] at bottom [19:22] well, the full thing.. [19:22] ok [19:23] i'll keep working to get networking up on it === dtp is now known as dtp-afk [19:43] smoser: re: network passthrough/netplan support; for zesty it's too late to switch to using netplan/systemd by default; so I'd like your opinion on how best to set a policy in the Distro object (or elsewhere that the Distro can use to select the right renderer) [19:47] well, rharper for ubuntu we have (i think) 3 cases: [19:47] a.) ifupdown without netplan: use ifupdown [19:47] b.) netplan without ifupdown: use netplan [19:48] c.) ifupdown and netplan: this is where we need a choice [19:48] correct; it's the (c) I was interested in [19:48] and i guess [19:48] d.) no ifupdown, no netplan: scream [19:49] yakkety and zesty; netplan (nplan) is seeded in the image (it's in main); so we're always in (c) for yak and zesty images [19:51] so i guess generically, we have a list of available "backends" that cloud-init will come up with. [19:51] in 'c', that'd be: available = ['ifupdown', 'netplan'] [19:51] renders [19:51] or something [19:51] eni and netplan [19:52] and sysconfig [19:52] ok. yeah. [19:53] i think that the distro should coome up with an ordered list of which are available. [19:54] available = ['eni', 'netplan'] [19:54] for 'c' above [19:54] and for 'a', that'd just be: available = ['eni'] [19:55] then, i guess we just have config (config/cloud.cfg i guess) that has a order of preference [19:56] system_info/network/render_priority = ['eni', 'sysconfig', 'netplan'] [19:56] and pick the first entry in render_priority that is also in available [19:56] ? [19:57] ok, so order of the available renders is the policy [19:58] so, for say UC16 (or to be named 17.10 release), we 'd update the list to indicate the preference [19:59] smoser: that seems reasonable; is config only reasonable? I know we do things like enumerate the DataSource classes to build a list; do we need to do that here for net/render.py to probe for possible renderers? [20:01] well, i think something has to do that. we can put a generic implementation in the distro class. [20:04] sure, but I'm questioning whether we're dynamically building that list from probing cloud-init .py files (or class loading); versus returning a list of known renderer names; [20:08] it has to be dynamic [20:08] such that in 'a', netplan is not available [20:08] we can allow a force of netplan even if the discovery says netplan isnt there. [20:09] well, there's whether cloud-init has a netplan renderer vs. whether the system has the tool to consume the rendered file [20:09] so, older cloud-inits won't have a config list with 'netplan' in it without a netplan class; but they system may have nplan package and netplan binary available [20:10] well, older cloud-inits wont read that list [20:10] they're just goign to pick eni [20:35] smoser: how's this look http://paste.ubuntu.com/24178612/ [20:39] rharper, hangout ? [20:39] y [20:39] http://c.brickies.net/hangout === dtp-afk is now known as dtp [21:11] rharper, r class loading); versus returning a list of known renderer names; [21:11] oos [21:11] https://bugs.launchpad.net/cloud-init/+bug/1671927 [21:13] http://paste.ubuntu.com/24178813/ [22:11] smoser i'm giving up on getting networking up on this thing [22:11] the command i need to run to add the default route is not working [22:11] i'll add more of the cloud-init log to the imgur [22:11] and let me know if there's anything else i can give === rangerpb is now known as rangerpbzzzz [22:30] smoser nevermind, i got the sr0 image [22:30] how do you want it?