[01:01] <smoser> mgagne, sorry. bzr
[01:01] <smoser> lp:cloud-init
[01:01] <mgagne> yea, I figured. thanks!
[01:24] <harlowja> mgagne  ya, were working on fixing that
[01:24] <harlowja> i mean smoser is gonna save us all
[01:40] <smoser> harlowja, right after you get the rhel networking sorted
[01:40] <smoser> :)
[01:40] <harlowja> lol
[01:40] <harlowja> oh ya, i'll try to do something there this week
[01:40] <smoser> :)
[01:40] <smoser> found / hit this today: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1571761
[01:40] <smoser> :-(
[01:40] <smoser> and with that  /me disapears
[01:40] <smoser> later gator.
[01:41] <harlowja> hmmmm, interesting, later
[07:57] <ReSam> good morning!
[07:57] <ReSam> I'
[07:58] <ReSam> I'm running MAAS and want to change my curtin_userdata preseed to install a few more things - but unfortunatley something always errors and then the exit code causes my deployment to fail
[07:58] <ReSam> what is the best way to "ignore the exit code" completely?
[07:59] <ReSam> I'm have lines like this in /etc/maas/preseeds/curtin_userdata:  puppet_02: curtin in-target -- sh -c 'dpkg -i /tmp/puppetlabs-release-pc1.deb'
[09:31] <Odd_Bloke> smoser: Is the expected behaviour of the 'fallback' networking to present network interfaces as eth{0,1,...} rather than the systemd names?
[09:36] <Odd_Bloke> rharper: ^
[09:36] <Odd_Bloke> If it isn't that's fine, I just got the impression that maybe that's what's meant to happen.
[09:36] <Odd_Bloke> And therefore want to know if I should be reporting if it isn't. :)
[09:44] <Odd_Bloke> (Oh, actually, maybe I'm being thrown off by a red herring: systemd leaves Hyper-V interfaces named eth* and I looked at Azure first; confirmation of the above would still be appreciated :)
[12:32] <rharper> Odd_Bloke: smoser  can confirm, but I don't think fallback does any renaming, so if you're booted without net.ifnames=0, and you have systemd, and fallback happens, you should see whatever systemd named the nic in the interfaces.d/50-cloud-init.cfg file
[12:33] <Odd_Bloke> OK, cool.
[12:34] <Odd_Bloke> smoser: rharper: So (assuming that to be true), do you have any suggestions for handling clouds that are sending network_config over in the meta_data.json, where content/0000 hard-codes eth0 as the expected network interface?
[12:34] <rharper> if
[12:34] <Odd_Bloke> (Other than going to the cloud and telling them to change what they're doing, of course ;)
[12:34] <Odd_Bloke> (Though we will try that)
[12:34] <rharper> if they are sending network_config via metadata service, we respect and use that
[12:34] <rharper> including naming
[12:35] <rharper> that's not fallback
[12:35] <rharper> we convert network_data.json into internal network_config.yaml which is then parsed and applied as if you had passed in a network_config.yaml in user-data
[12:35] <rharper> this is the configdrive stuff
[12:35] <Odd_Bloke> Yeah.
[12:35] <Odd_Bloke> Let me paste some things so we're on the same page.
[12:41] <Odd_Bloke> rharper: http://paste.ubuntu.com/15929016/
[12:41] <Odd_Bloke> So the cloud are just specifying an ENI file via meta_data.json and content/
[12:41] <Odd_Bloke> 0000
[12:41] <rharper> oh, this is network_config
[12:41] <rharper> unfortunate naming collision smoser and I discussed
[12:42] <rharper> Odd_Bloke: so, IIUC, cloud is providing an eni as-is;  however, it may not be aware of how nics will be named, right ?
[12:42] <Odd_Bloke> Right.
[12:42] <rharper> if they're sending ethX naming, and not also supplying an udev rule mapping file (70-persistent-net)
[12:42] <rharper> or network_config.yaml; then it's a bit of a shot in the dark
[12:43] <rharper> for Xenial (and wily), ensuring you boot with net.ifnames=0 will prevent nic naming to systemd style
[12:43] <rharper> which should match what they send; but the cloud itself should transition to using network_config.yaml
[12:44] <Odd_Bloke> rharper: Right; we're trying to get away from net.ifnames=0 as far as we can (because I suspect we will strongly regret having that delta in place for the next five years).
[12:44] <rharper> agreed
[12:44] <rharper> and the requirement is to specify what you want in network_config.yaml
[12:44] <rharper> alternatively, they can emit the ConfigDrive format that OpenStack uses
[12:44] <rharper> which cloud-init can convert to network_config.yaml
[12:45] <rharper> which emits the rules files needed to do name mapping
[12:45] <Odd_Bloke> rharper: Is there documentation that I can read/point them at?
[12:45] <rharper> y
[12:45] <rharper> one sec
[12:46] <rharper> https://blueprints.launchpad.net/nova/+spec/metadata-service-network-info
[12:46] <rharper> http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html
[12:48] <Odd_Bloke> rharper: So that's what they would put in /openstack/.../network_data.json, right?  How does network_config.yaml work?
[12:49] <rharper> it goes in the ConfigDrive at openstack/<date>/network_data.json
[12:49] <rharper> for network_config.yaml, lemme find the details
[12:51] <Odd_Bloke> rharper: Thanks. :)
[13:06] <smoser> Odd_Bloke, well, we need them to send the macs
[13:07] <smoser> and openstack does.
[13:13] <Odd_Bloke> smoser: From Liberty onward, right?
[13:14] <Odd_Bloke> (Can I tell what version of OpenStack I'm running on easily?)
[13:17] <smoser> the easiest way to do so is to look at the config drive.
[13:17] <smoser> or metadata service.
[13:17] <smoser> the version of the openstack isn't really exposed to the guest.
[13:18] <smoser> to further make it painful you actually have to have this fix applied to your liberty cloud : https://bugs.launchpad.net/nova/+bug/1513267
[13:18] <Odd_Bloke> So the most recent metadata version is 2013-10-17.
[13:20] <smoser> Odd_Bloke, https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L72
[13:21] <smoser> so they're ssomewhere between Havana and Liberty (Icehouse, Juno, or Kilo)
[13:21] <Odd_Bloke> smoser: So one of Hava, Icehouse, Juno or Kilo?
[13:21] <Odd_Bloke> Hah.
[13:21] <smoser> its not unreasonabel to request the newer metadata really...
[13:22] <smoser> if they want to provide network data to the guest, then that is how it is done, and any thing previous is just kind of crap.
[13:22] <smoser> we could maybe support the path where they made a /etc/network/interfaces style file available to the guest
[13:27] <Odd_Bloke> smoser: Assuming they aren't able to do network_config.json, is there any good path forward that might mean we can get something working on GA day?
[13:27] <Odd_Bloke> (I'm assuming cloud-init changes are out of scope for Thursday :p)
[13:27] <smoser> well, ga is almost certainly no.
[13:27] <smoser> right.
[13:28] <smoser> this is dreamhost ?
[13:28] <Odd_Bloke> Yep.
[13:28] <Odd_Bloke> Only their new region though.
[13:28] <smoser> and each instance has static ip configuration expected ?
[13:28] <Odd_Bloke> Their old region has a DHCP server.
[13:28] <smoser> how did they think this is supposed to work?
[13:28] <smoser> ie, if its static config, how does the host tell the guest what config to use
[13:29] <Odd_Bloke> Did you see http://paste.ubuntu.com/15929016/ ?
[13:36] <smoser> no sorry
[13:37] <smoser> Odd_Bloke, ok. so yeah, thats the old way of declaring it and we could prbosbaly without too much effort make that work
[13:37] <smoser> but not without some chagnes to cloud-init
[13:37] <Odd_Bloke> smoser: No need to be sorry. :)
[13:38] <Odd_Bloke> smoser: What would you envision those changes being, roughly?
[13:39] <smoser> the config drive datasource would just have to look in that path for config information and the parse the ENI format
[13:39] <smoser> and then apply it as networking.
[13:39] <smoser> we do have an ENI parser in cloud-init
[13:39] <smoser> and then a writer. so the pieces are mostly there.
[13:40] <smoser> the hwaddress bit is actually *wrong* in openstack's use.
[13:40] <smoser> ie, they're saying "eth0 is the nic with this mac address"
[13:40] <Odd_Bloke> How would it infer that the config for eth0 should actually be applied to network_interfaces[0]?
[13:40] <smoser> when ifupdown says "i shoudl change the nic named eth0 to use this mac address"
[13:40] <smoser> how would it infer ?
[13:42] <Odd_Bloke> Ohhh, I'd missed that they specified the MAC address.
[13:44] <Odd_Bloke> So cloud-init would rename the NIC with the MAC address specified there to eth0 and then apply that ENI config in ENI.d/50-cloud-init.cfg (or whatever that file is called)?
[13:44] <smoser> yeah.