[00:11] <meena> every time i try to touch cloudinit/config/schemas/schema-cloud-config-v1.json it just goes incredibly wrong
[00:14] <meena> jq is happy with it, but pytest is not
[00:14] <meena> not even almost
[09:41] <meena> yeah, okay, I have no idea how to extend a schema
[10:05] <meena> did you know: YAML is a superset of JSON
[10:05] <meena> but, you can't mix JSON and YAML syntax on the same line
[10:05] <meena> weird, huh?
[10:16] <meena> simple PR: https://github.com/canonical/cloud-init/pull/4143
[10:16] -ubottu:#cloud-init- Pull 4143 in canonical/cloud-init ".gitignore: extend coverage pattern" [Open]
[10:26] <meena> falcojr: thanks for the review, that triggered some thinking, and I have some simplification in mind
[10:48] <meena> falcojr: vastly simplified the code
[12:02] <meena> aciba[m]: got why time for https://github.com/canonical/cloud-init/pull/2157 — the code looks good, imo, but I'm not sure how to test it. i don't see anything else testing static route… stuff
[12:02] -ubottu:#cloud-init- Pull 2157 in canonical/cloud-init "Added / fixed support for static routes on OpenBSD and FreeBSD" [Open]
[12:42] <falcojr> meena: did you mean to ping me?
[13:18] <meena> falcojr: well, yesno. aciba[m] is awake, so i pinged him
[13:29] <meena> either way, https://github.com/canonical/cloud-init/pull/4119 is now very much ready
[13:29] -ubottu:#cloud-init- Pull 4119 in canonical/cloud-init "cc_rsyslog: Refactor for better multi-platform support" [Open]
[14:15] <greatgatsby_> Hi.  I think I'm hitting a race condition on almalinux 9.2 where sshd is trying to start before the host keys have been generated.  I'm thinking of overriding cloud-final.service to have a WantedBy and Before for sshd.service?  Has anyone experienced this and can offer a better solution?
[14:21] <meena> greatgatsby_: there's some precedent for that
[14:23] <greatgatsby_> so that's a reasonable solution?  I'm not super familiar with systemd dependencies, so I'm just hoping this will work.  
[14:29] <meena> greatgatsby_: i suggest looking in our git history / pull requests for a similar case and see how that was handled
[14:29] <greatgatsby_> ok great, thanks
[15:13] <greatgatsby_> meena: I found this, and it mentions revno 995
[15:13] <greatgatsby_> https://github.com/canonical/cloud-init/issues/2462
[15:13] -ubottu:#cloud-init- Issue 2462 in canonical/cloud-init "sshd can start before cloud-init injects keys" [Closed]
[15:14] <greatgatsby_> I'm not sure how to find the changes in revno (guessing revision number) 995
[15:19] <meena> yeah, no idea what that means, tbh
[15:23] <meena> greatgatsby_: oh, this was in the before time, when cloud-init was in bazaar 
[15:26] <greatgatsby_> oh I didn't see the date, yeah, 2014.  All the comments are from 2 weeks ago so I thought it was recent.
[15:26]  * meena isn't at the computer rn, and GitHub isn't as good as tig, sometimes
[15:32] <minimal> greatgatsby: Issues were moved from Launchpad to Github 2 weeks ago
[16:51] <greatgatsby_> just an update on some testing, I had thought this was the set-passwords module prematurely trying to start sshd, but I disabled that module and the problem persists.  
[16:57] <blackboxsw> greatgatsby_:  the commit that introduced this was the cloud-init.service not cloud-init.final https://github.com/canonical/cloud-init/commit/31621d585d183e09b3d857ef2a16bfb699b3a591 the question I have is what version of cloud-init is in your images, as this functionality was introduced in 2014.
[16:57] -ubottu:#cloud-init- Commit 31621d5 in canonical/cloud-init "run before sshd-keygen.service"
[16:58] <blackboxsw> systemd-analyze critical-chain ssh.service should tell you what ssh.service actually waits on.
[16:58] <blackboxsw> and cloud-init.service should be in that list of things that block ssh.service.
[17:01] <greatgatsby_> blackboxsw: thanks for the help.  It's 22.1 iirc.  I can see cloud-init start first, but then sshd tries to start shortly after and fails due to missing host keys.  This is the alma 9.2 qcow2 cloud image.
[17:02] <greatgatsby_> I do have those Wants/Before as you posted.  Correct me if I'm wrong, but the sshd-keygen.service doesn't even run if cloud-init is enabled due to another override, and it's cloud-init itself that generates the keys
[17:06] <greatgatsby_> due to this sshd-keygen drop-in:  ConditionPathExists=!/run/systemd/generator.early/multi-user.target.wants/cloud-init.target
[17:07] <greatgatsby_> so if cloud-init is enabled, sshd-keygen doesn't generate the keys, cloud-init does, and at some point after the first cloud-init service starts, sshd tries to start, but cloud-init hasn't created the keys yet (it just uses the ssh-keygen command iirc)
[17:12] <greatgatsby_> again, thanks for the help, this is just as I understand it
[17:23] <greatgatsby_> blackboxsw: I used systemd-analyze (thanks for that) and sshd.service is starting 105ms after cloud-init.service
[18:11] <blackboxsw> falcojr: upstream snapshot for 23.1 is merged. Do you want to do the honors for the dput to ubuntu with your new per package upload rights for Ubuntu/cloud-init?
[18:17] <falcojr> heh, sure
[18:17] <falcojr> blackboxsw: since you already checked the sbuild, there's no need for me to that right?
[18:32] <blackboxsw> falcojr: right, I ran it through all of it. just wondered if we can test out your new upload powers
[18:33] <blackboxsw> ..want to make sure permissions are all setup for that and we don't find some blocker to upload rights
[18:33] <falcojr> blackboxsw: currently getting gpg errors from build-package and trying to figure out why
[18:36] <blackboxsw> falcojr: that's because top-most changelog entry is signed by alberto.... so build-package would try to sign with his key by default, which you don't have.   You'll need to export GPGKEY=<your_rsa_pubkey> to debuild would use that key instead of trying to find alberto's
[18:36] <blackboxsw> `gpg --list-keys` will give that to you
[18:37] <blackboxsw> incidentally I also have set DEBFULLNAME='Chad Smith' and  DEBEMAIL=chad.smith@canonical.com which I believe also affect deb utilities
[18:37] <falcojr> yeah...I have all of those things alreadfy
[19:01] <dbungert> falcojr: are you doing a --sign-key=key-id when building the source package to point to your key id?
[19:03] <falcojr> dbungert: thanks...that particular flag also doesn't seem to work for me, but I was able to separately pass "-us -uc" to debuild followed up by a debsign, and that seemed to work
[19:16] <falcojr> blackboxsw helped me figure out the difference in our configs. He had "DEBSIGN_KEYID=<key>" in his ~/.devscripts so thats why he didn't need additional arguments
[21:38] <Saludos> Hola a todos / Hi everybody
[21:39] <Saludos> Alguien sabe como correr un script cloud-init (yaml) pero en una maquina que ya esta en ejecucion? a modo de probarlo?
[21:41] <meena> Saludos: replying in English, if that's okay:
[21:41] <Saludos> Yes
[21:41] <Saludos> Does anyone know how to run a cloud-init (yaml) script but on a machine that is already running? how to test it?
[21:42] <meena> Saludos: you can run cloud-init on a system, but it won't fully simulate what cloud-init would do
[21:42] <meena> because things are different during boot
[21:42] <Saludos> ooh, ok
[21:43] <Saludos> I thought that if it could
[21:44] <Saludos> i ran this
[21:44] <Saludos> cloud-init schema --config-file a.yaml
[21:44] <Saludos> the result is valid
[21:45] <Saludos> root@mando:/home/usuario# cloud-init schema --config-file a.yaml
[21:45] <Saludos> Valid cloud-config: a.yaml
[21:45] <meena> that's a good start
[21:45] <Saludos> but dont works
[21:47] <meena> I don't know if you can invoke cloud-init with a config it didn't fetch from the dedicated data source. unless that data source is already mounted
[21:54] <Saludos> Thanks
[22:29] <blackboxsw> Saludos: using lxd/lxc let's you quickly iterate and test #cloud-config by launching new instances with whatever your user-data is https://cloudinit.readthedocs.io/en/latest/tutorial/lxd.html
[22:30] <Saludos> thanks
[22:30] <blackboxsw> we typically do that locally when testing out new #cloud-config on our laptops as we are developing new features
[22:31]  * meena doesn't do that yet, because she'll have to port lxd-agent to FreeBSD
[22:31] <blackboxsw> :) meena I can't wait for that action/support when it comes
[22:31] <blackboxsw> it'll really ease integration tests for BSD
[22:32] <meena> I'm not sure i knew what i was signing up for, when getting on this project
[22:34] <meena> So far i have touched every corner of FreeBSD, and every corner of cloud-init few now lxd, I may have to look at wa Linux agent, and i will definitely have to get into building better FreeBSD images
[22:38] <meena> maybe i should try to do something really hard next, because every time in the past months I took on something i thought was gonna be easy, it turned out i was wrong
[22:44] <blackboxsw> Saludos: if lxd won't work for you, you could also use QEMU https://cloudinit.readthedocs.io/en/latest/tutorial/qemu.html
[22:46] <blackboxsw> meena: yeah maybe rewrite the kernel next.. it may only take a week
[22:48] <meena> blackboxsw: i do have some kernel work planned, but: it's unrelated to this project