00:18 <DemiMarie> elibrokeit: starting a VM in seconds is routine nowadays

00:19 <elibrokeit> that may or may not be true, considering that it was also irrelevant to my point

00:19 <elibrokeit> which was: you can't bring gitlab.com as an argument one way or the other

00:26 <DemiMarie> elibrokeit: fair

00:34 <DemiMarie> elibrokeit: I suspect they just use GCP VMs, which lets them offload the security concerns to GCP.

07:25 <bentiss> DemiMarie: re VM: I tried that setup when we initially switched to Hetzner: Hetzner has a fleeting plugin you can use to start VMs on demand. *but* hetzner charges VM by the hour. So you actually need to keep the VM up for 1 hour at least and share it with other jobs during this time or your costs are sky rocketting.

07:28 <bentiss> DemiMarie: But then, "how about we don't have a bare metal fleeting plugin on the bare metal servers we have, and that would solve the problem" -> answer is 2 points: technical debt (who is going to maintain that critical component), and also capaibilities, our CI extensively rely on VMs that are started in jobs. Hetzner (cloud) doesn't allow VM-in-VM, and I guess this will also

07:28 <bentiss> open a bunch of problems if we allow that too, so basically, we are breaking the biggest projects workflow

07:30 <bentiss> and 3 actually, there is the problem of the image the VM is running. I locally have a mac mini M4 and had to rely on LIMA (Linux Machine) to use it as a runner because podman was not a great option (not native virtualization). But the process is "take that container image with a kernel (a bootc image actually), convert it into a VM image, and then start the VM, wait for it to be

07:30 <bentiss> up, kexec the test kernel, and then start the script"

07:31 <bentiss> This process is fine in my case because I can cache the resulting VM image and reuse it. On a fdo scale, we can not, so we'll end up spending way too much time converting containers into VMs when all you need is a ruff command that takes seconds

07:32 <bentiss> TL;DR: starting a VM in seconds may be routine, prepping each VM is not and takes disk space and time

08:02 <bentiss> quick FYI, once again, the cloud credits on Hetzner are flatten by the sponsoring from Hetzner, and we only pay the dedicated servers :)

09:31 <svuorela> hmm.. we just discovered over in the kde sysadmin room that mesa is using kde's windows docker things in the version from before what KDE is now trying to retire... (so absolutely not updated, maintained or anything like that)

10:35 <machoskraito> hi all

11:51 <machoskraito> hi all back ... .