Hello,
I had a chat with @slp about a potential use case, specifically plugging in libkrun as part of the docker/podman executor workflow for GitLab CI. In GNOME we rely on the docker/podman executor for GitLab to execute hundreds of jobs per day, moving to a different solution (like cloud-hypervisor) would require re-architecting into using a different executor (Instance), while swapping the container runtime in podman is a much simpler task. There's a few requirements that we need though for libkrun to be easier to consume:
- Being able to use passt for all the containers that are spawned by the executor without touching the gitlab-runner executor's code at all
- Being able to override the kernel image libkrun uses with a configuration param (maybe part of containers.conf?)
- Being able to pass a krun_vm.json configuration file
- The krun_vm.json file should include a way to specify a block device the VM should use
@slp, with this specific set of requirements, how do you foresee us being able to handle the preparation of the VM for each build, i.e creating a new block device, running the VM, connecting to the VM using vsock or SSH, running the job, deleting the block device, all of this when using the docker/podman executor which doesn't give you that much freedom when it comes to job preparation as it's pretty opinionated. Am I missing something or potentially the only way to handle this would be through the GitLab CI custom executor?
Thanks!
Hello,
I had a chat with @slp about a potential use case, specifically plugging in libkrun as part of the docker/podman executor workflow for GitLab CI. In GNOME we rely on the docker/podman executor for GitLab to execute hundreds of jobs per day, moving to a different solution (like cloud-hypervisor) would require re-architecting into using a different executor (Instance), while swapping the container runtime in podman is a much simpler task. There's a few requirements that we need though for libkrun to be easier to consume:
@slp, with this specific set of requirements, how do you foresee us being able to handle the preparation of the VM for each build, i.e creating a new block device, running the VM, connecting to the VM using vsock or SSH, running the job, deleting the block device, all of this when using the docker/podman executor which doesn't give you that much freedom when it comes to job preparation as it's pretty opinionated. Am I missing something or potentially the only way to handle this would be through the GitLab CI custom executor?
Thanks!