[13:17] <minimal> with the recent rationalisation of module settings' names to use underscores rather than minuses should the names of modules in cloud.cfg.tmpl also standardise on using underscores?
[13:18] <falcojr> minimal: yes, both are currently supported but we should really standardize on one
[13:24] <minimal> perhaps I'll raise a PR to do this
[13:26] <minimal> also I'm confused about gateway4 & gateway6 in network-config v2 - recently I noticed these were depricated so changed my YAML files to use "route" instead. However a recent PR appears to have removed the deprecated note from the docs (though I don't see which PR did it)
[13:26] <minimal> so are gateway4/gateway6 deprecated or not for network-config v2?
[13:28] <falcojr> we removed the deprecated note? It's still deprecated for v2. For v1, we changed the netplan implementation to use routes instead
[13:29] <minimal> yupe, it was removed some time since Nov 21 (as I just did a "git pull" which last run then)
[13:29] <minimal> doc/rtd/topics/network-config-format-v2.rst was updated to remove the deprecated note
[13:30] <minimal> maybe because the previous note had a reference to "netplan#default-routes"? I'm using v2 with eni myself.
[13:31] <falcojr> hmmm, I think that might've just been a mistake/oversight
[13:50] <falcojr> I put up a PR to fix it. Thanks for letting us know!
[14:04] <minimal> np, I have another related issue to investigate as I have found that using "to: default" does NOT work for network-config v2 "routes:" (at least for eni)
[14:05] <minimal> the docs mention default but ~I had to use 0.0.0.0 to get it working
[14:22] <Teridon> I'm having with cloud-init 22.4.2-0ubuntu0~20.04.1 .  I defined 3 types of SSH host keys and certs in user-data.  All 3 keys and certs ended up in /etc/ssh/, but in sshd_config, there is only one HostCertificate line for the RSA key.  Did I do something wrong ?  user-data excerpt :   https://dpaste.org/EL03J   cloud-init.log:  https://dpaste.org/R1EhU   
[14:23] <Teridon> jeez.  obviously. "I'm having *a problem* with ... " 
[14:28] <minimal> Teridon: I don't understand the problem, you specified 3 different certs in user_data and 3 HostCertificate lines were written
[14:29] <falcojr> there's a single host certificate in /etc/ssh/sshd_config.d rather than all 3
[14:29] <minimal> ah, that it wrote 1 line, updating it 2 times
[14:30] <falcojr> Teridon: Looks like we have a bug. Would you mind filing this at https://bugs.launchpad.net/cloud-init ?
[14:31] <minimal> the sshd_config manpage entry for HostCertificate says "Specifies *a* file...", that's file singular
[14:31] <Teridon> You can specify HostCertificate multiple times
[14:31] <minimal> it's not clear if sshd_config can have multiple HostCertificate lines though
[14:32] <minimal> ok, the manpage doesn't indicate that either way
[14:32] <Teridon> yes it can.  I do that normally on all my systems...  and sshd presents the proper certificate depending on the key type you use to connect
[14:33] <Teridon> I will file a bug, thx
[14:35] <minimal> looks like the update_ssh_config_lines function only adds a line if it is not present and updates it otherwise, so doesn't cater for adding multiple such lines
[14:35] <minimal> in cloudinit/ssh_util.py
[15:27] <meena> https://github.com/canonical/cloud-init/compare/main...igalic:cloud-init:bsd/device_drivers?expand=1 i had to do this on my phone, because my laptop('s battery) died
[15:28] <meena> minimal: netplan runs on alpine?
[15:29] <meena> minimal: does netplan require dbus?
[15:32] <meena> https://github.com/canonical/netplan/blob/main/meson.build#L28 can't tell if this is a joke
[15:33] <falcojr> nah, I'm sure that find_program is searching the path...find is different
[15:35] <meena> anyway, i can't tell from that meson file of systemd and dbus are hard dependencies 
[15:38] <meena> can't find netplan here, https://git.alpinelinux.org/aports/log/?qt=grep&q=netplan 
[15:43] <minimal> meena: no, I'm using network-config v2 with eni, not netplan
[15:43] <minimal> what made you think I/Alpine was using netplan?
[15:45] <meena> minimal: my misreading of what you said
[15:46] <minimal> meena: there's no systemd on Alpine, someone tried to package it about 6 months ago and it didn't go down well...
[15:47] <meena> yeah, just looking at netplan's code, looks like it's deeply interwoven with systemd
[15:49] <minimal> meena: the issue with trying to get systemd on Alpine was two-fold, (1) the package submitter sort of indicated he was doing so to troll some Alpine people and (2) systemd people do not support musl and will accept any musl-related packages and so if an Alpine package was ever added it would have to carry around a large number of downstream patches forever
[15:50] <minimal> s/will accept/will not accept/
[15:50] <minimal> s/packages/patches/
[15:50] <minimal> my typing is awful today lol
[15:56] <meena> hands frozen?
[15:57]  * meena points at https://github.com/freebsd/freebsd-ports/tree/main/www/chromium/files
[15:57] <minimal> nope, probably not enough/too much coffee ;-)
[16:00] <meena> most of these patches are so trivial it's deeply frustrating 
[16:02] <meena> https://github.com/freebsd/freebsd-ports/blob/main/www/chromium/files/patch-chrome_browser_metrics_power_process__metrics__recorder__util.cc
[16:03] <meena> AIX: chromium supported platform. BSD? nope
[17:06] <Teridon> I tried to submit a bug at https://bugs.launchpad.net/cloud-init/+filebug but the site had some kind of error
[17:07] <blackboxsw> checking Teridon an OOPS message ?
[17:07] <Teridon> yes.  Unfortunately I didn't get the code.  I tried to go back to my bug form to resubmit but it was gone 
[17:07] <blackboxsw> that route looks like it works for me... checking to see if your bug got submitted
[17:08] <blackboxsw> hrm latest bug I see is https://bugs.launchpad.net/cloud-init/+bug/1999042. so something didn't submit
[17:08] -ubottu:#cloud-init- Launchpad bug 1999042 in cloud-init "In openEuler, distro.osfamily is incorrect" [Undecided, New]
[17:09] <Teridon> let me try again I guess
[17:14] <Teridon> Well I think I got the bug submitted (1999164) but I just failed to add an attachment (Error ID: OOPS-487354aacd8f1d4dbe05652042959d86) 
[17:42] <Teridon> got both my attachments done.  I guess it was something with my proxy ‍ https://bugs.launchpad.net/cloud-init/+bug/1999164 
[17:42] -ubottu:#cloud-init- Launchpad bug 1999164 in cloud-init "when multiple SSH host key certificates are defined, only one HostCertificate is referenced in sshd_config" [Undecided, New]
[18:50] <minimal> falcojr: remember when I mentioned an issue a month ago where I was having problems on Alpine with the boot services and cloud-init.log all complained about distro being ubuntu and I eventually figured out it was a syntatically invalid /etc/cloud/cloud.cfg file?
[18:52] <minimal> I had had another similar report on Alpine and it think it was introduced in cloud-init in a PR between 22.3 and 22.4 - the 2nd line of cloud.cfg.tmpl is a blank line and once the jinja templating occurs to create cloud.cfg that 2nd blank line becomes a blank 1st line, which yamllint says in a syntax error
[18:52] <blackboxsw> do tell minimal: invalid YAML?
[18:52] <blackboxsw> interesting. checking commit history there
[18:54] <blackboxsw> wow so a blank line is a yaml error?
[18:54] <blackboxsw> checking yamllint behavior
[18:56] <blackboxsw> it's most likely this commit https://github.com/canonical/cloud-init/commit/cd2cca35a1  but hrm.
[18:56] -ubottu:#cloud-init- Commit cd2cca3 in canonical/cloud-init "Create reference documentation for base config"
[19:05] <minimal> blackboxsw: not simple a blank line, I believe the *1st* line of a valid YAML file cannot be blank
[19:06] <minimal> yamllint says:
[19:06] <minimal>   1:1       error    too many blank lines (1 > 0)  (empty-lines)
[19:07] <blackboxsw> hrm.yet yaml.safe_load('\n\n1:2') seems to process fine :/
[19:07] <holmanb> looks like a configurable yamllint value
[19:07] <holmanb> https://yamllint.readthedocs.io/en/stable/rules.html#module-yamllint.rules.empty_lines
[19:09] <blackboxsw> I have no qualms with us dropping that leading new line. ... it's not needed for anything and as part of a jinja template it doesn't make sense to have the spacer anyway
[19:09] <blackboxsw> as the file will get processed before rendering.
[19:10] <minimal> yeah it's certainly technically not valid to have it
[19:10] <blackboxsw> minimal: is there something else that is malformed in the jinja rendered cloud.cfg file?
[19:10] <blackboxsw> besides the leading empty newlin
[19:10] <minimal> it may not be the underlying cause of the issue the person is having, I'm now getting more feedback and it might be something else
[19:11] <minimal> it seems they are replacing the cloud.cfg with their own version that doesn't have "system_info:" section or "distro:" subsection" so that's probably the root cause of their fallback to ubuntu
[19:13] <minimal> don't know how it works for them with other distros then
[19:14] <blackboxsw> for karma :) https://github.com/canonical/cloud-init/pull/1902
[19:14] -ubottu:#cloud-init- Pull 1902 in canonical/cloud-init "cloud.cfg.tmpl: drop leading newline in jinja-rendered YAML content" [Open]
[19:15] <minimal> blackboxsw: I'll raise a PR to fix various cloud.cfg.tmpl warning/errors that yamllint flags
[19:16] <blackboxsw> minimal: that's better. than my tongue in cheek pr 1902 :)
[19:16] <blackboxsw> I'll close it