[00:30] <minimal> meena: it uses the "fallback" setup - if writes DHCPv4 config (in cloud-init "init-local" stage) via the appropriate renderer, then OS runs its usual mechanism to setup networking (using the rendered config file), then cloud-init ("init" stage) uses the available networking to fetch the seed URLs
[00:31] <minimal> if the fetched "meta-data" document defines any network config then *again* cloud-init uses the appropriate renderer to write that network config
[00:31] <meena> that sounds mostly sensible.
[00:32] <minimal> the problem/issue is that the "fallback" config is write and then the OS uses it, rather than (like with AWS etc) cloud-init doing a "ip addr" etc to temporarily setup the networking
[00:32] <minimal> the temporary network config should NOT be rendered
[00:33] <minimal> it is only needed to be able to fetch the seed URLs, at which point either network config from the seed URLS, or else *then* fallback network config should be used/rendered
[00:49] <minimal> meena: so I'd say writing a temporary network config to OS config files is not sensible - the DataSources that talk to metadata servers do not do this for example
[00:50] <minimal> think of the server hosting the http/https YAML files as being a very "simple" metadata server
[01:12] <minimal> I tested git master (with the ds fix) and as expected it worked like I previously saw with c-i 23.1.1. I then added the "network-config=disabled" cmdline option - the c-i "init-local" stage no longer rendered the fallback DHCP config to eni, as it didn't do this then the OS used the eni file (created by c-i during the previous boot using network config from seed meta-data URL) and the c-i "init" stage then attempted to access the seed URLs but failed 
[01:12] <minimal> as the ip address/subnet (set by OS from eni file) is different from that obtained via DHCP and so machine did not have connectivity to the http server hosting the seed content, which it would have if it had used DHCP again instead
[01:14] <minimal> so this causes problems if any network config in the seed documents uses a different subnet, uses VLANs, etc from that of the DHCP server
=== esv_ is now known as esv
[07:11] <caribou> blackboxsw: thanks for the attention. I'm release our images with 23.2 in -proposed which will be overriden by our new SRU one when it hits updates
=== hyperreal9 is now known as hyperreal
[14:46] <minimal> I tested c-i main with freshly booting a nocloud-net config with network-config=disabled on the cmdline and, as expected, c-i "init-local" did not create the fallback network config, and so the OS did not bring up the ethernet, and so the c-i "init" stage failed to retrieve the seed URLS, and so no cloud-init module configuration was performed
[14:46] <minimal> I'll test next with specifying network config on the cmdline
[14:48] <minimal> BTW the above test did not just silently fail, there were code errors on screen and in the cloud-init.log file
[15:01] <blackboxsw> Filed bug on downstream Ubuntu apport behavior for SRU https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2025376
[15:01] -ubottu:#cloud-init- Launchpad bug 2025376 in cloud-init (Ubuntu) "apport general hooks break on type annotations" [Critical, Triaged]
[15:01] <blackboxsw> this only affects focal and needs to be in what we SRU to focal for 23.2.1
[15:49] <blackboxsw> https://github.com/canonical/cloud-init/pull/4216 up for review for focal
[15:49] -ubottu:#cloud-init- Pull 4216 in canonical/cloud-init "Ubuntu/focal 23.2.x" [Open]
[16:00] <blackboxsw> thanks for review falcojr aciba[m] I've uploaded 23.2.1-0ubuntu0~20.04.2 to launchpad and ppa:cloud-init-dev/proposed