| meena | every time i try to touch cloudinit/config/schemas/schema-cloud-config-v1.json it just goes incredibly wrong | 00:11 |
|---|---|---|
| meena | jq is happy with it, but pytest is not | 00:14 |
| meena | not even almost | 00:14 |
| meena | yeah, okay, I have no idea how to extend a schema | 09:41 |
| 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:05 |
| 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:16 | |
| meena | falcojr: thanks for the review, that triggered some thinking, and I have some simplification in mind | 10:26 |
| meena | falcojr: vastly simplified the code | 10:48 |
| 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:02 | |
| falcojr | meena: did you mean to ping me? | 12:42 |
| meena | falcojr: well, yesno. aciba[m] is awake, so i pinged him | 13:18 |
| 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] | 13:29 | |
| 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:15 |
| meena | greatgatsby_: there's some precedent for that | 14:21 |
| greatgatsby_ | so that's a reasonable solution? I'm not super familiar with systemd dependencies, so I'm just hoping this will work. | 14:23 |
| 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 | 14:29 |
| 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:13 | |
| greatgatsby_ | I'm not sure how to find the changes in revno (guessing revision number) 995 | 15:14 |
| meena | yeah, no idea what that means, tbh | 15:19 |
| meena | greatgatsby_: oh, this was in the before time, when cloud-init was in bazaar | 15:23 |
| 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:26 | |
| minimal | greatgatsby: Issues were moved from Launchpad to Github 2 weeks ago | 15:32 |
| 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:51 |
| 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:57 | |
| 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. | 16:58 |
| 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:01 |
| 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:02 |
| greatgatsby_ | due to this sshd-keygen drop-in: ConditionPathExists=!/run/systemd/generator.early/multi-user.target.wants/cloud-init.target | 17:06 |
| 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:07 |
| greatgatsby_ | again, thanks for the help, this is just as I understand it | 17:12 |
| greatgatsby_ | blackboxsw: I used systemd-analyze (thanks for that) and sshd.service is starting 105ms after cloud-init.service | 17:23 |
| 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:11 |
| falcojr | heh, sure | 18:17 |
| falcojr | blackboxsw: since you already checked the sbuild, there's no need for me to that right? | 18:17 |
| blackboxsw | falcojr: right, I ran it through all of it. just wondered if we can test out your new upload powers | 18:32 |
| 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:33 |
| 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:36 |
| 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 | 18:37 |
| dbungert | falcojr: are you doing a --sign-key=key-id when building the source package to point to your key id? | 19:01 |
| 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:03 |
| 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 | 19:16 |
| Saludos | Hola a todos / Hi everybody | 21:38 |
| Saludos | Alguien sabe como correr un script cloud-init (yaml) pero en una maquina que ya esta en ejecucion? a modo de probarlo? | 21:39 |
| 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:41 |
| 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:42 |
| Saludos | I thought that if it could | 21:43 |
| Saludos | i ran this | 21:44 |
| Saludos | cloud-init schema --config-file a.yaml | 21:44 |
| Saludos | the result is valid | 21:44 |
| 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:45 |
| 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:47 |
| Saludos | Thanks | 21:54 |
| 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:29 |
| 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:30 |
| * 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:31 |
| meena | I'm not sure i knew what i was signing up for, when getting on this project | 22:32 |
| 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:34 |
| 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:38 |
| blackboxsw | Saludos: if lxd won't work for you, you could also use QEMU https://cloudinit.readthedocs.io/en/latest/tutorial/qemu.html | 22:44 |
| blackboxsw | meena: yeah maybe rewrite the kernel next.. it may only take a week | 22:46 |
| meena | blackboxsw: i do have some kernel work planned, but: it's unrelated to this project | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!