Some ideas to improve Guix on the Cloud

Guix has great story for configuring software on Guix systems. The main obstacle to using Guix on the cloud is getting Guix running in the first place. One can manually follow the install process on each VPS. But ideally the installation process would be to automated so that we can treat our servers like cattle not pets.

To reduce the scope of work needed, we would like to use opentofu to provision infrastructure and Guix to configure the systems. Guix has some code to call the APIs of cloud providers, like [digitalocean], to create resources. But opentofu already has most of the cloud providers covered. And because it is widely used, the providers themselves tend to do the work to integrate with opentofu.

Under the hood opentofu uses calls to those API to inspect the existing resources and determine what we need to create, modify or destroy to match the desired state. There isn't a reason why that work couldn't happen in guile, but in the interested of keeping the scope reduced it makes more sense to use the existing solutions instead.

Automating the installer

The guix installer is an executable written in guile scheme. It is written as a TUI, which uses newt, and a set of functions which perfoms the changes. The TUI which prompts the users for questions, while the functions perform the work.

For example, here is the main menu for the partition screen is here. It uses [guile-parted] to perform the work. It should be possible to replace the respones from the menu with either canned respones of functions that query its enviroment to determine the disk and available space.

cloud-init

Cloud-init provides for a way to customize cloud instances. In particular it provides a way to customize the initial installation process. It can be used to as a way to configure Guix so that one can run guix deploy on the node.

Cloud-init the software are collection of python scripts that are called from systemd and sysint services. There is very little Guix can use as Guix uses shepherd as its init system. However Cloud-init is also a standard set of HTTP endpoint that providers us to expose information about the instance. For example the instance metadata endpoint.

One way to leverage cloud-init would be to write a shepherd service that grabs the ssh key provided by the user and configures openssh to authorized the key. Another way cloud-init could help is for the user to provide the the system configuration to use after install.

Note that RDE has some support for cloud-init, it has a service that obtains information about what disk sizes the instance has available and uses it to create the disk partitions.

How would an MVP look like?

The goal is to have a working Guix system we can use guix deploy to configure after running tofu apply. To that end we want an ISO image we can use as a custom image. The image should runs an automated installer that partitions the disk to use all available space, configures the the network and sets up openssh with the ssh key listed in the the metadata endpoint.

To achieve that we need to go through the installer steps, and figure either a prefined response or a strategy to obtain the information we need to perform the step. Obtaining the informaiton from the metadata endpoint is vendor specific. E.j. Hetzner is at http://169.254.169.254/hetzner/v1/metadata. Its format is YAML. The digital ocean endpoint is at http://169.254.169.254/metadata/v1.json. Its format is JSON. That means that we would need an image per Cloud provider.