Re: Thoughts on stateful services in Guix

["Ludovic Courtès" <ludo@gnu.org>]

Hi Alex,

Thanks for sharing your thoughts and this tricky but important use case!

Alex Sassmannshausen <alex.sassmannshausen@gmail.com> skribis:

> 3 A generalisation: the Stateful-Service Service
> ════════════════════════════════════════════════
>
>   State dumping and restoration *should* be generalisable.
>
>   It should normally consist of one or more operations of:
>   • running a special program to dump data, encrypting the dump, and
>     storing it, together with the service revision hash, in a known
>     location.
>   • tarring up a directory tree, encrypting the archive and storing it,
>     together wtih the service revision hash, in a known location.
>
>   These operations should be able to be provided by a daemon, managed by
>   shepherd, which can be configured with a gpg key for encryption, a
>   mechanism for decryption (interactive or programmatic), a location for
>   storing/retrieving dumps (local or remote?), and a DSL for mapping
>   data dump / data restoration program invocations or file-system
>   locations to data dumps it already knows of.

Back in my Nix days, Wouter den Breejen worked on “S-Nix”, whose goal
was to explore how Nix could be extended to support state¹.  Back then,
I think the experiment was not considered fruitful, in part due to its
complexity, the implementation’s reliance on ext3cow, things like that.

There may still be good ideas to take from that, although it’s probably
more reasonable to start with something simple and practical, trying to
address a couple of concrete use cases before trying to generalize.
What you propose above sounds like it could be a good start!

Ludo’.

¹ “Managing state in a purely functional deployment model”, master
  thesis,
  <http://www.cs.uu.nl/education/scripties/scriptie.php?SID=INF/SCR-2007-053>.
  I couldn’t find a copy on-line so here’s one from my attic:
  <http://web.fdn.fr/~lcourtes/tmp/snix-thesis.pdf>.