=== lowercase is now known as lowercase00
=== esv_ is now known as esv
[18:31] <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:51] <falcojr> akutz: or some kind of long-poll socket, but yes, something along those lines if somebody wants to opt-in to it
[19:35] <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:36] <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:49] <holmanb> @blackboxsw: no problem at all, looking now
[20:00] <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:01] <falcojr> akutz: yes, it's runtime
[20:03] <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:08] <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:09] <akutz> Yes, thank you. So I can imagine an eventual 'updates: network: when: ["hotplug", "metadata"]'
[20:12] <falcojr> as of right now, yes, something like that
[20:16] <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:17] <blackboxsw> awiating CI, then we should be able to squash merge with the suggested commit msg in the description
[20:23] <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:25] <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:26] <holmanb> @blackboxsw: thanks!
[20:30] <falcojr> akutz: not exactly sure I follow, but across most datasources, metadata URLs should still be reachable after boot has finished
[20:32] <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:34] <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:35] <falcojr> akutz: right, yeah, there's still a lot of details to work out
=== lowercase is now known as lowercase00