[13:17] <lucasmoura> blackboxsw, thanks for the review on the apt_configure schema :) I have addressed the issues you raised
[13:18] <lucasmoura> 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] <rick_h> lucasmoura:  always feel free to call out follow ups as long as what's there isn't broken.
[13:39] <rick_h> lucasmoura:  more smallers prs > bigger giant ones generally
[13:40] <lucasmoura> rick_h, yes, that's true
[13:40] <lucasmoura> Thanks rick_h :)
[15:33] <dingus9> 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] <Odd_Bloke> blackboxsw: Lucas has reviewed https://github.com/canonical/cloud-init/pull/347 so it's ready for your core review BTW.
[16:27] <blackboxsw> 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.
[18:57] <blackboxsw> 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] <lucasmoura> 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] <lucasmoura> I am fine with whatever suits you best :)
[22:10] <robjo> rharper: still around?
[22:11] <rharper> robjo: not supposed to be, but here I am =)
[22:11] <robjo> yay me
[22:11] <robjo> another networking problem :( of course
[22:12] <robjo> when there are multiple interfaces is there a way in the config to make sure we get the "right" assignment?
[22:12] <robjo> i.e. can cloud-init rename interfaces?
[22:12] <rharper> yes, it does
[22:13] <robjo> 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] <robjo> I have a case where a 10.x.x.x network sometimes shows up on eth0 and sometimes on ethX
[22:13] <rharper> 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] <robjo> that look up then means we get the random kernel discovered names, right?
[22:14] <rharper> only the first time, afterwards we emit udev rules to bind the name to the mac
[22:15] <robjo> the answer then is the user needs to specify "name" and then the mac is force to be associated with that name?
[22:15] <rharper> however, if you retain eth* namespaces, you sometimes lose because of hotplug racing with cloud-init (or udev) renaming
[22:15] <rharper> for manual configs, yes, for automated (platform) configs, we usually have what we need via metadata service info
[22:15] <robjo> right, there is always the race condition
[22:15] <rharper> correct, however, cloud-init will use the written config and manuall rename interfaces on each boot
[22:16] <rharper> ideally it's already fixed byt cloud-init local time due to udev being complete
[22:16] <robjo> well the metadata doesn't contain the interface names
[22:16] <rharper> no
[22:16] <rharper> but it has macs
[22:16] <robjo> it contains "id"
[22:16] <rharper> and we look it up on first boot, and then it's "fixed" in udev rules and rendered network config files
[22:17] <robjo> right but somehow this still has to be stiched together
[22:17] <robjo> it's the first boot that's the problem
[22:17] <rharper> first boot isn't a problem
[22:18] <robjo> according to the customer it is
[22:18] <rharper> 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] <rharper> it says eth0; so we emit udev rule that binds MAC1 with the name 'eth0';
[22:18] <rharper> we write config to disk, that includes the ip/netmask/dhcp for "eth0";
[22:18] <rharper> repeat for each additional interface
[22:19] <rharper> 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] <robjo> 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] <rharper> sure, but only once, on the first boot
[22:19] <rharper> 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] <rharper> that happens either via udev or cloud-init
[22:20] <robjo> 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] <rharper> yes, and we do that
[22:20] <rharper> 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] <robjo> 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] <rharper> I see;
[22:21] <rharper> there's nothing we can do about that;
[22:21] <rharper> the openstack metadata would need to include a specific name
[22:21] <robjo> Thanks, that's what I thought
[22:21] <rharper> we originally did want to use the 'id' field to set the interface name
[22:22] <rharper> but that's not part of the network_json specification;
[22:22] <rharper> so we had to use the lookup
[22:22] <robjo> glad I have not fallen off the rocker
[22:22] <rharper> hehe, it just wasn't clear to me that the first boot pairing (which we persist) wasn't the mapping they desired
[22:23] <robjo> thanks for the help
[22:23] <rharper> sure