[17:22] <dtp> 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
[18:17] <smoser> dtp, can you give the config drive that you ave?
[18:17] <dtp> smoser some of the files are available at http://imgur.com/a/qEElh
[18:18] <dtp> and others are attached to the bug.  or is there another you need?
[18:18] <smoser> dtp, you couldnt use pastebin ? for text :)
[18:19] <dtp> i don't have net access to the VM / only have spice console
[18:19] <smoser> dtp, so the issue... is that cloud-init did not write that /etc/network/interfaces
[18:19] <smoser> as it says, nova "injected" it.
[18:19] <smoser> essentially, your cloud platform broke your image by thinking it knows what it is doing.
[18:19] <smoser> and cloud-init does not attempt to un-break it for that scenario.
[18:20] <smoser> that make sense ?
[18:20] <dtp> which /etc/network/interfaces?
[18:20] <smoser> i'm 95% certain that nova mounted the image and write /etc/network/interfaces
[18:20] <smoser> oh wait.
[18:20] <smoser> no.
[18:20] <smoser> ok. let me re-think
[18:20] <dtp> this is fedora 25 / no /etc/network/interfaces, only network-scripts/... files
[18:20] <smoser> right
[18:21] <dtp> so where i'm coming from is this all worked on fedora 23 w/ older cloud-init
[18:21] <dtp> trying to get fedora 25 up
[18:22] <smoser> you're right. it sure would appear that cloud-init is preferring to parse the 0000 file
[18:22] <smoser> theres no way you can get the disk there?
[18:23] <dtp> which file do you need?
[18:23] <smoser> you shoudl be able to bring up networking by hand
[18:23] <smoser> if you just get me the config drive (dd if=/dev/vdb of=my.img)
[18:23] <smoser> or something to that affect, thats the easiest.
[18:23] <dtp> ok, i'm in a meeting but will after
[19:10] <smoser> dtp, just reading code, it sure seems like it should be looking at the network json in 0.7.8
[19:11] <dtp> 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] <smoser> well if you attached a config drive then it should be reading that.
[19:12] <smoser> there is a config drive, right ?
[19:12] <smoser> thats what you showed with 'cat' ?
[19:12] <smoser> yeah
[19:13] <dtp> yeah
[19:13] <dtp> they were saying something else in the config drive caused it to ignore network_data.json
[19:13] <dtp> meta_data i think
[19:13] <dtp> but i didn't see much in there
[19:15] <smoser> hm.
[19:15] <smoser> can you show me ls /sr0/openstack/ ?
[19:17] <dtp> smoser - http://imgur.com/a/YXfc5 - still working on bringing network up
[19:19] <smoser> hm.
[19:19] <smoser> that wasnt what i expected :)
[19:19] <dtp> oh?
[19:20] <smoser> that should work. i expected that you were going to honly have 2016-10-06 and 2017-02-22
[19:20] <dtp> 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] <dtp> so it wasn't making it there before it went to write net conf
[19:21] <dtp> i guess the trace is in that original imgur
[19:22] <dtp> would explain how it skipped that part
[19:22] <smoser> 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] <dtp> yeah, that's in the imgur already - http://imgur.com/a/qEElh
[19:22] <dtp> at bottom
[19:22] <smoser> well, the full thing..
[19:22] <dtp> ok
[19:23] <dtp> i'll keep working to get networking up on it
[19:43] <rharper> 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] <smoser> well, rharper for ubuntu we have (i think) 3 cases:
[19:47] <smoser> a.) ifupdown without netplan: use ifupdown
[19:47] <smoser> b.) netplan without ifupdown: use netplan
[19:48] <smoser> c.) ifupdown and netplan: this is where we need a choice
[19:48] <rharper> correct; it's the (c) I was interested in
[19:48] <smoser> and i guess
[19:48] <smoser> d.) no ifupdown, no netplan: scream
[19:49] <rharper> 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] <smoser> so i guess generically, we have  a list of available "backends" that cloud-init will come up with.
[19:51] <smoser> in 'c', that'd be: available = ['ifupdown', 'netplan']
[19:51] <rharper> renders
[19:51] <smoser> or something
[19:51] <rharper> eni and netplan
[19:52] <rharper> and sysconfig
[19:52] <smoser> ok. yeah.
[19:53] <smoser> i think that the distro should coome up with an ordered list of which are available.
[19:54] <smoser> available = ['eni', 'netplan']
[19:54] <smoser> for 'c' above
[19:54] <smoser> and for 'a', that'd just be: available = ['eni']
[19:55] <smoser> then, i guess we just have config (config/cloud.cfg i guess) that has a order of preference
[19:56] <smoser> system_info/network/render_priority = ['eni', 'sysconfig', 'netplan']
[19:56] <smoser> and pick the first entry in render_priority that is also in available
[19:56] <smoser> ?
[19:57] <rharper> ok, so order of the available renders is the policy
[19:58] <rharper> so, for say UC16 (or to be named 17.10 release), we 'd update the list to indicate the preference
[19:59] <rharper> 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] <smoser> well, i think something has to do that. we can put a generic implementation in the distro class.
[20:04] <rharper> 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] <smoser> it has to be dynamic
[20:08] <smoser> such that in 'a', netplan is not available
[20:08] <smoser> we can allow a force of netplan even if the discovery says netplan isnt there.
[20:09] <rharper> well, there's whether cloud-init has a netplan renderer vs. whether the system has the tool to consume the rendered file
[20:09] <rharper> 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] <smoser> well, older cloud-inits wont read that list
[20:10] <smoser> they're just goign to pick eni
[20:35] <rharper> smoser: how's this look http://paste.ubuntu.com/24178612/
[20:39] <smoser> rharper, hangout ?
[20:39] <rharper> y
[20:39] <smoser> http://c.brickies.net/hangout
[21:11] <smoser> rharper, r class loading); versus returning a list of known renderer names;
[21:11] <smoser> oos
[21:11] <smoser> https://bugs.launchpad.net/cloud-init/+bug/1671927
[21:13] <smoser> http://paste.ubuntu.com/24178813/
[22:11] <dtp> smoser i'm giving up on getting networking up on this thing
[22:11] <dtp> the command i need to run to add the default route is not working
[22:11] <dtp> i'll add more of the cloud-init log to the imgur
[22:11] <dtp> and let me know if there's anything else i can give
[22:30] <dtp> smoser nevermind, i got the sr0 image
[22:30] <dtp> how do you want it?