=== tds9 is now known as tds [13:17] blackboxsw, thanks for the review on the apt_configure schema :) I have addressed the issues you raised [13:18] Also, I think I can address the description problem, that it is not allowing more advanced formatting like lists or notes. But should we do that on the same PR ? [13:39] lucasmoura: always feel free to call out follow ups as long as what's there isn't broken. [13:39] lucasmoura: more smallers prs > bigger giant ones generally [13:40] rick_h, yes, that's true [13:40] Thanks rick_h :) === hjensas is now known as hjensas|afk [15:33] anyone know of tooling to generate cloud-init yml configs on the hypervisor side? maybe that also pack it into an iso? thanks [16:05] blackboxsw: Lucas has reviewed https://github.com/canonical/cloud-init/pull/347 so it's ready for your core review BTW. [16:27] lucasmoura: rick_h as mentioned in standup, unfortunately our docs on readthedocs are auto-generated from tip of cloud-init, so if we introduce a breaking doc change it'll render to the docs shortly thereafter. So, we probably should be cognizant of this fix PR in this case. lucasmoura and I can meet today to sort it. === tds5 is now known as tds [18:57] Odd_Bloke: +1 will check that PR out today for the dot printing. I think https://github.com/canonical/cloud-init/pull/339 is ready for review per our discussion yesterday. I used https://github.com/canonical/uss-tableflip/pull/48 to generate it. I see you have doc comments on #48. were you awaiting doc closure there before we land groovy new-upstream-snapshot? [19:35] blackboxsw, I think I have arrived in a solution for description formatting issue. I can show you the meeting or commit it to the PR so you can review [19:35] I am fine with whatever suits you best :) [22:10] rharper: still around? [22:11] robjo: not supposed to be, but here I am =) [22:11] yay me [22:11] another networking problem :( of course [22:12] when there are multiple interfaces is there a way in the config to make sure we get the "right" assignment? [22:12] i.e. can cloud-init rename interfaces? [22:12] yes, it does [22:13] the kernel discovers the interfaces in "random" order, how does cloud-init decide which interface gets associated with the config passed in by the user? [22:13] I have a case where a 10.x.x.x network sometimes shows up on eth0 and sometimes on ethX [22:13] right, so, if the network config includes mac addresses (and there isn't a set-name, or name specified) we look up the name of the interface by the mac [22:14] that look up then means we get the random kernel discovered names, right? [22:14] only the first time, afterwards we emit udev rules to bind the name to the mac [22:15] the answer then is the user needs to specify "name" and then the mac is force to be associated with that name? [22:15] however, if you retain eth* namespaces, you sometimes lose because of hotplug racing with cloud-init (or udev) renaming [22:15] for manual configs, yes, for automated (platform) configs, we usually have what we need via metadata service info [22:15] right, there is always the race condition [22:15] correct, however, cloud-init will use the written config and manuall rename interfaces on each boot [22:16] ideally it's already fixed byt cloud-init local time due to udev being complete [22:16] well the metadata doesn't contain the interface names [22:16] no [22:16] but it has macs [22:16] it contains "id" [22:16] and we look it up on first boot, and then it's "fixed" in udev rules and rendered network config files [22:17] right but somehow this still has to be stiched together [22:17] it's the first boot that's the problem [22:17] first boot isn't a problem [22:18] according to the customer it is [22:18] for each interface in openstack, we extract the mac address, and before we write udev rules or network-config to disk, we "ask" the kernel, what name do you have for this macaddress [22:18] it says eth0; so we emit udev rule that binds MAC1 with the name 'eth0'; [22:18] we write config to disk, that includes the ip/netmask/dhcp for "eth0"; [22:18] repeat for each additional interface [22:19] then, on next boot, udev runs and *should* already enforce the correct names; in addition to that, cloud-init reads the config on disk (which includes the original mac to name mapping) and will use ip rename to enforce MAC1 has the name eth0 [22:19] but that is the point, we ask the kernel the name for the interface, so we depend on the discovery order of the interfaces [22:19] sure, but only once, on the first boot [22:19] so every boot after that can randomly change, and we will *rename* eth1 back to eth0 if eth1 has MAC1 which should be on eth0 [22:20] that happens either via udev or cloud-init [22:20] Yes, but they want the same order every time, i.e. the 10.x.x.x network always needs to be associated with eth0 [22:20] yes, and we do that [22:20] so if you've got the log, and udev rules and system journal, we can see if there's a bug in there; but we've had this behavior for years now; [22:20] but there is no guarantee that the mach they give us is at the time we ask associated with eth0, it could be associated with eth2 [22:21] I see; [22:21] there's nothing we can do about that; [22:21] the openstack metadata would need to include a specific name [22:21] Thanks, that's what I thought [22:21] we originally did want to use the 'id' field to set the interface name [22:22] but that's not part of the network_json specification; [22:22] so we had to use the lookup [22:22] glad I have not fallen off the rocker [22:22] hehe, it just wasn't clear to me that the first boot pairing (which we persist) wasn't the mapping they desired [22:23] thanks for the help [22:23] sure