[01:01] mgagne, sorry. bzr [01:01] lp:cloud-init [01:01] yea, I figured. thanks! [01:24] mgagne ya, were working on fixing that [01:24] i mean smoser is gonna save us all [01:40] harlowja, right after you get the rhel networking sorted [01:40] :) [01:40] lol [01:40] oh ya, i'll try to do something there this week [01:40] :) [01:40] found / hit this today: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1571761 [01:40] :-( [01:40] and with that /me disapears [01:40] later gator. [01:41] hmmmm, interesting, later [07:57] good morning! [07:57] I' [07:58] 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] what is the best way to "ignore the exit code" completely? [07:59] 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] smoser: Is the expected behaviour of the 'fallback' networking to present network interfaces as eth{0,1,...} rather than the systemd names? [09:36] rharper: ^ [09:36] If it isn't that's fine, I just got the impression that maybe that's what's meant to happen. [09:36] And therefore want to know if I should be reporting if it isn't. :) [09:44] (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 :) === shardy is now known as shardy_lunch === shardy_lunch is now known as shardy [12:32] 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] OK, cool. [12:34] 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] if [12:34] (Other than going to the cloud and telling them to change what they're doing, of course ;) [12:34] (Though we will try that) [12:34] if they are sending network_config via metadata service, we respect and use that [12:34] including naming [12:35] that's not fallback [12:35] 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] this is the configdrive stuff [12:35] Yeah. [12:35] Let me paste some things so we're on the same page. [12:41] rharper: http://paste.ubuntu.com/15929016/ [12:41] So the cloud are just specifying an ENI file via meta_data.json and content/ [12:41] 0000 [12:41] oh, this is network_config [12:41] unfortunate naming collision smoser and I discussed [12:42] 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] Right. [12:42] if they're sending ethX naming, and not also supplying an udev rule mapping file (70-persistent-net) [12:42] or network_config.yaml; then it's a bit of a shot in the dark [12:43] for Xenial (and wily), ensuring you boot with net.ifnames=0 will prevent nic naming to systemd style [12:43] which should match what they send; but the cloud itself should transition to using network_config.yaml [12:44] 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] agreed [12:44] and the requirement is to specify what you want in network_config.yaml [12:44] alternatively, they can emit the ConfigDrive format that OpenStack uses [12:44] which cloud-init can convert to network_config.yaml [12:45] which emits the rules files needed to do name mapping [12:45] rharper: Is there documentation that I can read/point them at? [12:45] y [12:45] one sec [12:46] https://blueprints.launchpad.net/nova/+spec/metadata-service-network-info [12:46] http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html [12:48] rharper: So that's what they would put in /openstack/.../network_data.json, right? How does network_config.yaml work? [12:49] it goes in the ConfigDrive at openstack//network_data.json [12:49] for network_config.yaml, lemme find the details [12:51] rharper: Thanks. :) [13:06] Odd_Bloke, well, we need them to send the macs [13:07] and openstack does. [13:13] smoser: From Liberty onward, right? [13:14] (Can I tell what version of OpenStack I'm running on easily?) [13:17] the easiest way to do so is to look at the config drive. [13:17] or metadata service. [13:17] the version of the openstack isn't really exposed to the guest. [13:18] 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] So the most recent metadata version is 2013-10-17. [13:20] Odd_Bloke, https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L72 === rangerpbzzzz is now known as rangerpb [13:21] so they're ssomewhere between Havana and Liberty (Icehouse, Juno, or Kilo) [13:21] smoser: So one of Hava, Icehouse, Juno or Kilo? [13:21] Hah. [13:21] its not unreasonabel to request the newer metadata really... [13:22] 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] we could maybe support the path where they made a /etc/network/interfaces style file available to the guest [13:27] 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] (I'm assuming cloud-init changes are out of scope for Thursday :p) [13:27] well, ga is almost certainly no. [13:27] right. [13:28] this is dreamhost ? [13:28] Yep. [13:28] Only their new region though. [13:28] and each instance has static ip configuration expected ? [13:28] Their old region has a DHCP server. [13:28] how did they think this is supposed to work? [13:28] ie, if its static config, how does the host tell the guest what config to use [13:29] Did you see http://paste.ubuntu.com/15929016/ ? [13:36] no sorry [13:37] 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] but not without some chagnes to cloud-init [13:37] smoser: No need to be sorry. :) [13:38] smoser: What would you envision those changes being, roughly? [13:39] the config drive datasource would just have to look in that path for config information and the parse the ENI format [13:39] and then apply it as networking. [13:39] we do have an ENI parser in cloud-init [13:39] and then a writer. so the pieces are mostly there. [13:40] the hwaddress bit is actually *wrong* in openstack's use. [13:40] ie, they're saying "eth0 is the nic with this mac address" [13:40] How would it infer that the config for eth0 should actually be applied to network_interfaces[0]? [13:40] when ifupdown says "i shoudl change the nic named eth0 to use this mac address" [13:40] how would it infer ? [13:42] Ohhh, I'd missed that they specified the MAC address. [13:44] 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] yeah. === rangerpb is now known as rangerpbzzzz