| === lowercase is now known as lowercase00 | ||
| === esv_ is now known as esv | ||
| akutz | What is the expectation of the METADATA_CHANGE when it is eventually funded? Do we expect that it will respond at runtime? Ex. will cloud-init maintain a loop that polls the DS for changes? | 18:31 |
|---|---|---|
| falcojr | akutz: or some kind of long-poll socket, but yes, something along those lines if somebody wants to opt-in to it | 18:51 |
| blackboxsw | falcojr: holmanb sorry for delay. Here is a PR to help address ds-identify detection of LXD KVM instances when launched from Jammy | 19:35 |
| blackboxsw | https://github.com/canonical/cloud-init/pull/1370 | 19:35 |
| ubottu | Pull 1370 in canonical/cloud-init "ds-identify: detect LXD for VMs launched from host with > 5.10 kernel" [Open] | 19:35 |
| blackboxsw | took me a while to write up the related bug | 19:36 |
| blackboxsw | as I'd like to target that bug for fixing in Jammy | 19:36 |
| blackboxsw | https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1968085 | 19:36 |
| ubottu | Launchpad bug 1968085 in cloud-init (Ubuntu) "Jammy: ds-identify: cloud-init disabled by generator due to inability to detect LXD datasource when launched from Jammy host system" [High, In Progress] | 19:36 |
| holmanb | @blackboxsw: no problem at all, looking now | 19:49 |
| akutz | falcojr: that sounds about right, thanks for the confirmation. my real question was to understand whether the METADATA_CHANGE event was intended to be another boot time event or runtime. If it's runtime then it's what I expected it would be. I'm thinking of when users want to add NICs or modify network settings from outside the guest and how to pipe that information into the guest. | 20:00 |
| falcojr | akutz: yes, it's runtime | 20:01 |
| akutz | falcojr: nice. is there any plumbing in place yet for runtime reconfig of networking yet? I'm not talking about the eventing work, but just the ability to cause a network reconfig post-boot. I might be tempted to work on the eventing if the networking side was already present. | 20:03 |
| falcojr | akutz: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#install-hotplug is what turns it on. https://github.com/canonical/cloud-init/blob/main/cloudinit/cmd/devel/hotplug_hook.py is what we run in response to the udev event | 20:08 |
| falcojr | is that what you're looking for? | 20:08 |
| akutz | Yes, thank you. So I can imagine an eventual 'updates: network: when: ["hotplug", "metadata"]' | 20:09 |
| falcojr | as of right now, yes, something like that | 20:12 |
| blackboxsw | oooh, I'm getting excited with that conversation about hotplug metadata :) | 20:16 |
| blackboxsw | holmanb: just pushed flake fixes and updated the requested commit msg. | 20:16 |
| blackboxsw | on 1370 | 20:16 |
| blackboxsw | awiating CI, then we should be able to squash merge with the suggested commit msg in the description | 20:17 |
| akutz | falcojr: by the way, thanks for the confirmation on the networkd thing. I spoke with the other VMware engineer, and he agrees it's an issue we should resolve. We discussed two options, and he's considering which one to use. | 20:23 |
| falcojr | sounds good | 20:23 |
| akutz | Crud -- I just realized the challenge on metadata updates. Where our updates do not require networking, EC2 and other datasources get that info from their ephemeral DHCP network. I imagine by the time the instance is online it can no longer access that metadata URL? Or maybe it can? I do not really know. So yeah, ultimately to opt-in to supporting this, datasources would have to revaluate how/when they are able to provide metadata. | 20:25 |
| holmanb | @blackboxsw: thanks! | 20:26 |
| falcojr | akutz: not exactly sure I follow, but across most datasources, metadata URLs should still be reachable after boot has finished | 20:30 |
| akutz | Ack. I wasn't sure since EC2 uses the ephemeral DHCP network to grab its metadata. I wasn't sure if that meant the URL was no longer available once the actual network is up. | 20:32 |
| akutz | And my point is that since many DSs use networking to check metadata, cloud-init's own polling mechanism would likely want to be aware of that and not be over-eager in checking for MD changes (since it could result in network traffic). It's up to the DS though -- it could use a websocket to just "watch" the MD endpoint. I imagine CI would say "our polling interval and how you poll should be completely divorced from one another." | 20:34 |
| falcojr | akutz: right, yeah, there's still a lot of details to work out | 20:35 |
| === lowercase is now known as lowercase00 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!