An error occurred while fetching this tab.
libvirt-executor improvements
- Dec 15, 2024
-
-
Kristian Klausen authoredThere is no technical reason for this at the moment, but UEFI is the de facto firmware for x86-64, so let's be modern.
-
Kristian Klausen authored
This should not change anything as the VMs are short-lived (15 minutes at the most), so it is just added for good measure.
-
Kristian Klausen authored
From the kernel patch series[1]: "This series provides an asynchronous means of reporting free guest pages to a hypervisor so that the memory associated with those pages can be dropped and reused by other processes and/or guests on the host. Using this it is possible to avoid unnecessary I/O to disk and greatly improve performance in the case of memory overcommit on the host."[1] The runner hosts may be memory overcommitted if there is too many running VMs and containers at the same time, which this should help to avoid. [1] https://lore.kernel.org/linux-mm/20200211224416.29318.44077.stgit@localhost.localdomain/
-
Kristian Klausen authored
It makes more sense to build the image in arch-boxes than building it on each runner, especially considering that arch-boxes already have all the necessary infrastructure, so we can avoid maintaining similar code in two repositories and avoid running losetup, mount, arch-chroot etc. (as root) on the runners. The arch-boxes MR[1] has a little more context. [1] archlinux/arch-boxes!200
-
Kristian Klausen authored
This reverts commit 466230e4. This has been fixed in pacman[1], so it is no longer unreasonably slow. Some quick testing at runner1 indicates that this only saves five seconds at best, so IMO it is not worth the complexity to continue doing this. This revert does not revert the timeout back to 60 seconds, but keeps it at 30 seconds. [1] pacman/pacman!16
-
Kristian Klausen authored
This means that there is no need to make runner-specific changes to the image, so in theory the image could be build centrally (e.g. in the arch-boxes project[1]) and then distributed to the runner hosts. This change also make the SSH keys ephemeral. [1] https://gitlab.archlinux.org/archlinux/arch-boxes
-
Kristian Klausen authored
All libvirt volume management is now handled through virsh instead of direct file system access. As a volume cannot be uploaded in an atomic way, the current active volume is now tracked in a file on disk. This may allow us to run the script with less privileges and use polkit for libvirt access control[1]. [1] https://libvirt.org/aclpolkit.html
-
Kristian Klausen authored
The prepare stage runs "echo "Running on $(hostname)...""[1], resulting in "bash: line 7: hostname: command not found" and it outputting "Running on ..." as the hostname command is provided by inetutils, which is not installed. Fix it by "monkey patching" it to use "hostnamectl hostname" and inject the hostname with SMBIOS[2][3]. Injecting creds with SMBIOS may also be useful in the future, e.g. for injecting an ephemeral SSH public key. [1] https://gitlab.com/gitlab-org/gitlab-runner/-/blob/v17.5.2/shells/bash.go?ref_type=tags#L452-L456 [2] https://systemd.io/CREDENTIALS/ [3] https://github.com/systemd/systemd/pull/30814
-
Kristian Klausen authored
This removes 13 instances of [1] and 1 instance of the IP address from the job log. The latter was fixed by no longer waiting for SSH in the "run" stage, which is unnecessary as we wait for SSH in the "prepare" stage. [1] Warning: Permanently added '192.168.122.xxx' (ED25519) to the list of known hosts.
-
Kristian Klausen authored
It was forgotten once[1] to update it in both places, so avoid that issue in the future, by moving it to a variable. [1] c370c9d0 ("gitlab_runner: Update concurreny math to reflect the new VM size")
-
Kristian Klausen authored
-