It's time to build "guix deploy"

[Christopher Lemmer Webber]

Hi,

This has come up several times.  A lot of us want "guix deploy".
Personally, I'm running a variety of Debian servers and one Guix server
and I am terrible at maintaining all of them.

It's time for Guix Deploy... or it's time for me to give up and use
something like Ansible + Debian.  (Egads!  I don't want to do that.)

David's thoughts on this are below, and here's the original thread:

Original thread can be found at the links below:
  https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00525.html
  https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00007.html
  https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00006.html

There is a heavily, heavily bitrotted branch named "wip-deploy" where
David originally started exploring these ideas.  Conveniently, it's all
in one commit:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy&id=fcd6fc84e493d05be1f7590ee77509c81ac315c2

That seems like a good starting point.  But I know David feels that with
real-world experience in devops type work that actually things would be
a bit different than what's described in his original email.  I'm not
sure myself what would be different.  It would be helpful to hear Dave
weigh in on that point.

Maybe Dave and I can meet up IRL now that we're close enough to each
other to chat about it.  But I know it's less fun than it used to be for
Dave to consider this because now that's Dave's actual job... but all
the more reason we need Dave's wisdom! :)


David Thompson writes:

> Hey folks,
>
> I'm writing this in an attempt to "think out loud" about a deployment
> automation tool for GuixSD.
>
> Guix needs a NixOps[0] equivalent.  NixOps is the Nix project's
> deployment automation tool.  I read the source code[1] a bit, and here's
> what I've learned about it:
>
> * The central data type is a "deployment", which is a Nix expression
>   consisting of one or more named OS configs
>
> * The OS configs contain extra data that specifies the target platform:
>   VirtualBox, EC2, NixOS container, etc.  Each platform implements the
>   generic MachineDefinition and MachineState interfaces.
>
> * The 'nixops' command is stateful.  It stores necessary state about
>   deployed systems in a special directory ($HOME/.nixops by default),
>   such as the IP addresses of the deployed systems.  Because of this,
>   each deployment needs a unique identifier.
>
> * Deployments may be parameterized by values known only at deploy time.
>   This covers cases such as a web application server needing to know the
>   IP address of the database server.
>
> * There are useful subcommands to check the status of each system or ssh
>   into one of them.
>
> Here's a rough outline of how I'm thinking of implementing similar
> features in Guix:
>
> * Introduce new data types:
>
>   * <platform>: The generic interface type for implementing deployment
>     targets.  Its fields hold procedures for various actions like
>     'provision', 'destroy', 'boot', or 'reboot'.  I haven't determined
>     the precise list of actions needed, but it will become apparent as
>     platforms are added.
>
>   * <machine>: Describes a single system in the deployment.  Contains a
>     name string, an <operating-system>, and a <platform>.
>
>   * <deployment>: Contains a name string and a list of <machine> and
>     procedures.  Procedures in the list should accept an argument
>     containing the deployment results of the non-parameterized machines
>     and return a <machine>.
>
> * Use a simple s-exp deployment state format.  Store the state in
>   $HOME/.config/guix by default.
>
> * Implement a 'guix ops' subcommand roughly the same actions as NixOps:
>   create, deploy, start, stop, destroy, list, info, check, ssh, etc.
>
> * The bulk of the work will be creating <platform> objects that actually
>   provision various types of resources.  For prototyping, a
>   'local-vm-platform' would be enough to test that the whole system
>   works.
>
> Anyone want to join in on this brainstorming party?  Your thoughts are
> appreciated!
>
> [0] http://nixos.org/nixops/
> [1] https://github.com/NixOS/nixops