| smoser | mgagne, sorry. bzr | 01:01 |
|---|---|---|
| smoser | lp:cloud-init | 01:01 |
| mgagne | yea, I figured. thanks! | 01:01 |
| harlowja | mgagne ya, were working on fixing that | 01:24 |
| harlowja | i mean smoser is gonna save us all | 01:24 |
| 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:40 |
| harlowja | hmmmm, interesting, later | 01:41 |
| ReSam | good morning! | 07:57 |
| ReSam | I' | 07:57 |
| 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:58 |
| 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' | 07:59 |
| 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:31 |
| 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:36 |
| 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 :) | 09:44 |
| === shardy is now known as shardy_lunch | ||
| === shardy_lunch is now known as shardy | ||
| 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:32 |
| Odd_Bloke | OK, cool. | 12:33 |
| 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:34 |
| 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:35 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| Odd_Bloke | rharper: So that's what they would put in /openstack/.../network_data.json, right? How does network_config.yaml work? | 12:48 |
| rharper | it goes in the ConfigDrive at openstack/<date>/network_data.json | 12:49 |
| rharper | for network_config.yaml, lemme find the details | 12:49 |
| Odd_Bloke | rharper: Thanks. :) | 12:51 |
| smoser | Odd_Bloke, well, we need them to send the macs | 13:06 |
| smoser | and openstack does. | 13:07 |
| Odd_Bloke | smoser: From Liberty onward, right? | 13:13 |
| Odd_Bloke | (Can I tell what version of OpenStack I'm running on easily?) | 13:14 |
| 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:17 |
| 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:18 |
| smoser | Odd_Bloke, https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L72 | 13:20 |
| === rangerpbzzzz is now known as rangerpb | ||
| 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:21 |
| 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:22 |
| 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:27 |
| 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:28 |
| Odd_Bloke | Did you see http://paste.ubuntu.com/15929016/ ? | 13:29 |
| smoser | no sorry | 13:36 |
| 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:37 |
| Odd_Bloke | smoser: What would you envision those changes being, roughly? | 13:38 |
| 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:39 |
| 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:40 |
| Odd_Bloke | Ohhh, I'd missed that they specified the MAC address. | 13:42 |
| 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. | 13:44 |
| === rangerpb is now known as rangerpbzzzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!