Thanks for the advices. OK, supporting both ISO and PXE seems to be the way to go if they have different performance characteristics. (I haven’t tried out PXE yet, but I plan to)
I’m thinking that this GitHub Action could be useful for CI, demos and bug reports. It would be nice to be able to create a demo for some software and at the same time be able to use the demo for automatic tests in continuous integration (CI) and potentially catch new bugs. It would be easy to provide instructions for how to reproduce such bugs when writing bug reports.
I added some new functionality so that it is now possible to configure how many VM instances each Butane should have.
Today I made a test where a VM ran a Nginx container with Podman and two VMs ran curl to fetch the default web page from the Nginx webserver. It worked!
The networking part of the code needs improvement. I would like to get DHCP working. Currently the IP address is provided via a dracut kernel command line option ip=...
(see man dracut.cmdline
).
I would like to highlight one design aspect that is quite fortunate: Both GitHub Action workflows and Butane use YAML. There is no need to wrap Butane configurations in some other format. Instead they can be provided as subtrees in the input to the GitHub Action. It is possible to copy-paste the Butane config from somewhere else, and then just add some extra indentation to use it in the GitHub Action workflow.
An interesting design question is whether or not the ignition files need to be ready before starting the VMs. In case they are not ready one could hope that they will be ready before any timeout would occur during the HTTP requests.
I found some timeout configuration parameters in the Butane file format specifications (for instance Fedora CoreOS Specification v1.4.0) but I couldn’t find any timeout configuration for the ignition.config.url kernel parameter.
If anyone is curious, currently the GitHub Action takes about 1 minute and 45-55 seconds to run. Allocating the GitHub-hosted runner might also take some time (often about 15 seconds).
One could hope that PXE could speed up booting. Besides having no dependencies on coreos-installer and OCR, the VM could start booting
as soon as the kernel and initramfs files have been downloaded. I guess the big rootfs file does not need to be ready from the very beginning of the boot process.
Regarding the speed of the GitHub cache:
When I tested half a year ago I noticed that it was slightly faster to download the Fedora CoreOS ISO from the official URL than it was to download a previously cached Fedora CoreOS ISO from the GitHub cache. Currently the GitHub Action uses the GitHub cache ( @actions/tool-cache
). I will do some testing to see which way is the fastest.
About the status of the code
The code is still experimental and in a flux. I’ll need to clean it up.