=== janitha8 is now known as janitha
=== paride1 is now known as paride
[20:06] <holmanb> Does anybody know why cloud-init-local doesn't log many events (for cloud-init analyze)?
[22:39] <akutz> Someone is hitting a weird error with the Cluster API VM images - https://github.com/kubernetes-sigs/image-builder/issues/712. Looks like a KeyError (more info in link) when parsing the network config for DNS. Except here is where it gets odd. The provided metadata matches the network v2 config example from https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html, where "nameservers" is how you specify DNS info for a given
[22:39] <akutz>  interface. But the code, which hasn't changed in 5 years in this section, says the key should be "dns" - https://github.com/canonical/cloud-init/blame/main/cloudinit/net/network_state.py#L133-L146.
[22:39] <ubottu> Issue 712 in kubernetes-sigs/image-builder "[Ubuntu] Cloud-init failing with KeyError: id0" [Open]
[23:16] <blackboxsw> holmanb: each event is parsed from /var/log/cloud-init.log as defined by any section of code that has a designated by bookend log lines  starting with CI_EVENT_MATCHES = ['start:', 'finish:', 'Cloud-init v.']. There is a cloudinitutil.log_time functon invoked to add those timed logs and there is a context manager too that generates those events
[23:17] <blackboxsw> there just aren't as many events wrapped in the log_time function in init-local
[23:33] <holmanb> @blackboxsw: thanks, that makes sense. After asking here, I tried wrapping each stage in main_init() with events.ReportEventStack(), but the blame/show parser outputs didn't show some events. Since that code is used for both cloud-init init --local and cloud-init init I think the duplicate name/desc duplication broke things. I was able to hack my way around that, but even with unique names a single boot is getting 
[23:33] <holmanb> broken into multiple boot records for some reason (current guess is that nested calls aren't supported?). 
[23:36] <falcojr> akutz: haven't looked too deeply at that one yet, but since we support two different network config formats, we covert them both to a universal intermediary state. I'm pretty sure that anything in that NetworkState class involves that intermediary state, and not the original v1/v2 config
[23:37] <akutz> Ack
[23:37] <holmanb> @blackboxsw - I don't plan to pursue this much further, unless folks think it would be valuable to do so. I was just poking at it since I noticed that systemd-analyze critical-chain and cloud-init analyze show were reporting different numbers (>1s) for init-local's runtime
[23:38] <akutz> falcojr: I dug in further, and until they give more info, I am holding off. That repo still builds Ubuntu 20.04, but the log shows Cloud-Init 21.3+20.04.3. Except they also install my old DS. It seems they may be doubling up the datasources, and who knows what will happen then. I'm asking them for clarity. Thanks for looking!
[23:44] <akutz> falcojr: Yeah, they were doing a dist upgrade to 20.04.3 and CI 21.3 and not removing my old DS. Not sure that's the smoking gun, but it's not good, that's for sure.
[23:44] <akutz> Thanks for looking!