| === tds9 is now known as tds | ||
| lucasmoura | blackboxsw, thanks for the review on the apt_configure schema :) I have addressed the issues you raised | 13:17 |
|---|---|---|
| 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:18 |
| 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:39 |
| lucasmoura | rick_h, yes, that's true | 13:40 |
| lucasmoura | Thanks rick_h :) | 13:40 |
| === hjensas is now known as hjensas|afk | ||
| dingus9 | anyone know of tooling to generate cloud-init yml configs on the hypervisor side? maybe that also pack it into an iso? thanks | 15:33 |
| Odd_Bloke | blackboxsw: Lucas has reviewed https://github.com/canonical/cloud-init/pull/347 so it's ready for your core review BTW. | 16:05 |
| 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. | 16:27 |
| === tds5 is now known as tds | ||
| 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? | 18:57 |
| 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 :) | 19:35 |
| robjo | rharper: still around? | 22:10 |
| rharper | robjo: not supposed to be, but here I am =) | 22:11 |
| robjo | yay me | 22:11 |
| robjo | another networking problem :( of course | 22:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| robjo | thanks for the help | 22:23 |
| rharper | sure | 22:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!