GNU bug report logs - #74389
[PATCH] services: add cloud-init service

Previous Next

Full log

Message #11 received at 74389 <at> debbugs.gnu.org (full text, mbox):

From: Alex <alex <at> infiniteadaptability.org>
To: "74389 <at> debbugs.gnu.org" <74389 <at> debbugs.gnu.org>
Subject: [PATCH] services: add cloud-init service
Date: Fri, 22 Nov 2024 19:20:13 +0000

Ricardo,

This patch is just a MVP for implementing a cloud-init service. The goal primarily was to get the networking, disk and filesystem mounts, and ssh authentication working properly.

From a high level this patch implements a cloud-init-service which uses cloud-init functionality to gather information from it's run-time environment and then run cloud-init modules in order to properly configure the vm. It provides a configuration interface for choosing which modules to run as well as a mechanism to add extra configuration files.

I took a few major shortcuts in order to get a working image.

The first is that instead of writing guix specific functionality for cloud-init modules, I decided to attempt to use the ubuntu (which I believe is the default) tools. This is why the cloud-utils package as well as the network-manager-service-type are included in the vm image template I created as part of this patch.

The second shortcut is that I didn't see a good way to guix-ify the cloud-init service definitions/runtime environment (i.e. I used the /etc/cloud directory to handle most of the configuration files). I'd prefer if configuration lives in the store, but the configuration files and the gathered data live in locations which I didn't see a way to overwrite easily. I'm sure this exists, but would require more digging into the cloud-init source code and/or patches that would need to be pushed upstream.

The final shortcut is the actual running of the cloud-init-service. I didn't see a good way to *wait* for a process to complete, i.e. to block other services until the current service completes. It looks to me that running a long-running one-shot service (each stage of cloud-init typically takes a few seconds to run) doesn't block any service which requires it's provisions. Maybe there's some shepherd nuances that I'm not aware of. I ended up creating a computed file which produces a shell script which runs each cloud-init stage in sequence as a workaround to a more robust solution.

I added some extra comments with instructions on how to add extra cloud-init configuration files. This is required for cloud-init to run properly on DigitalOcean (the order of the data sources needs to be changed from the default). It might be necessary for other p

I've tested this on digital ocean and gotten it work properly (and then used guix deploy to update the configuration of the image). 

NOTE: there are some comments in the template file that would need to be uncommented to build the exact image I used.

Using this patch it should be easy to create an image for testing using:

./pre-inst-env guix system image -t qcow2 gnu/system/examples/cloud-init-image.tmpl

I would appreciate further testers and any suggestions for improvement.

Thanks!

Alex

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.