Re: cloud-init?

[David Dashyan <mail@davie.li>]

Hi Simon!

I've been interested in adding cloud-init support for a while already.
It would make Guix much easier to use in a cloud setting.  I did ask
people weather anyone is interested in it couple of times in #guix and
also mentioned it on the mailing list couple of times.  People didn't
seem to express much interest but once they have it they'll like it a
lot I think :) It is common practice to spawn other distro type and turn
it into Guix or install Guix on it and do "guix system init" on mounted
volume and then swap them.  Not to mention the fact that every now and
then there is a new question on running Guix on some other vendor.  Guix
deploy was made exactly for that in mind, wasn't it?

I hacked together a little module that provides "cloud-init" service
that makes a query to DigitalOcean HTTP API hosted on link-local address
and does some essential stuff like configure the network, add SSH key
and resize partitions and filesystem.

https://github.com/ipdb/bigchaindb-guix/blob/master/bigchaindb-guix/services/cloud-init.scm

So as you see I went in a different direction - rather than integrating
actual cloud-init package I just made a Guile substitute for it.  I am
not sure which approach is best though.

There are many cloud vendors and they all have slightly different APIs.
On the other side, my guess is that cloud-init (the real one) is
designed specifically to work with systemd and Debian derived
distributions.  I am not sure which way is a bigger hassle — to rewrite
it our-self or try and add Guix support to cloud-init.  I doubt that
cloud-init team would be interested in Guix support upstreaming either.

I tend to think that adding Guix-style cloud-init service could still be
easier in the end.  APIs don't differ that much and are pretty stable,
plus all investigation is already done by cloud-init team — I didn't
even read DigitalOcean docs when I wrote my module I just looked up what
cloud-init does.  But I'm interested in your opinion on it.

Wait there is more on Guix cloud-init service.  If you followed the code
above, what it essentially does is it compiles a giant g-expression that
does everything.  As a result I borrowed some code from already existing
Guix services.  If cloud-init service was to do more it would mean even
more duplication.  But it is not how I wanted in a first place.  It
ended up like this because as I found out later that 1.) not all module
are importable into a g-expression so I can't just import other Guix
services procedures and reuse them 2.) you need to know all service-type
arguments in advance (which not compatible with having idea of
cloud-init at all :)).  I think you can't spawn one service from another
service either, you'll probably need to dig deeper and reach shepherd
for that.  But I am not sure about that.  Someone mentioned "recursive
derivations" that are not yet possible when I discussed that topic.  But
it would be cool if there was a way for Guix cloud-init service to query
the environment compose and start other Guix services at startup.
So-called "user-data" can be also used in interesting way too.  There
could be a "user-data" guile record that extends operating system
somehow rather that bash-script.

All in all I am glad I am not the only one interested in it.

Cheers,
-- 
David