guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guix "ops"


From: David Thompson
Subject: Guix "ops"
Date: Mon, 27 Apr 2015 19:38:37 -0400
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)

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

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate



reply via email to

[Prev in Thread] Current Thread [Next in Thread]