unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: David Thompson <dthompson2@worcester.edu>
Cc: guix-devel@gnu.org
Subject: Re: Guix "ops"
Date: Thu, 30 Apr 2015 17:25:39 +0200	[thread overview]
Message-ID: <87vbgdy6x8.fsf@gnu.org> (raw)
In-Reply-To: <87k2wx6t1e.fsf@fsf.org> (David Thompson's message of "Mon, 27 Apr 2015 19:38:37 -0400")

David Thompson <dthompson2@worcester.edu> skribis:

> I'm writing this in an attempt to "think out loud" about a deployment
> automation tool for GuixSD.

Yay, good idea!

> * 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.

Oh, I remember “charon create” creating this ‘network.json’ file
containing the list of machines and the file names of the Nix expression
used to create that deployment.

I’m not 100% clear on why this state needs to be stored; it seems more
like a cache to me, no?  That is, Charon/NixOps can always recreate it
from the source Nix expressions.

> * 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.

OK.

>   * <machine>: Describes a single system in the deployment.  Contains a
>     name string, an <operating-system>, and a <platform>.

Yes (it’s best to keep it separate from <operating-system>; in NixOps
it’s a ‘deployment’ attribute in the OS attribute set.)

>   * <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>.

OK.

> * Use a simple s-exp deployment state format.  Store the state in
>   $HOME/.config/guix by default.

Or ~/.cache/guix?

> * 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.

Sure.

> Anyone want to join in on this brainstorming party?  Your thoughts are
> appreciated!

It seems you already have all the requirements and design options
in mind!

Thanks,
Ludo’.

  reply	other threads:[~2015-04-30 15:25 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27 23:38 Guix "ops" David Thompson
2015-04-30 15:25 ` Ludovic Courtès [this message]
2015-04-30 16:53   ` David Thompson
2015-05-01 14:48     ` Ludovic Courtès
2015-05-04 23:51       ` Carlos Sosa
2015-05-05  2:00         ` David Thompson
2015-05-05  7:57           ` Ludovic Courtès
2015-05-07  3:02             ` Christopher Allan Webber
2015-05-22 14:59         ` David Thompson
2015-05-22 16:06           ` Ludovic Courtès
2015-05-22 16:24             ` David Thompson
2015-05-27 18:47               ` Carlos Sosa
2015-05-28 16:10                 ` Thompson, David
2015-05-27 19:41               ` Ludovic Courtès
2015-05-28 16:13                 ` Thompson, David
2015-07-09 18:27               ` OpenStack and GuixOps (was: Re: Guix "ops") Christopher Allan Webber
2015-07-10  2:18                 ` Ian Denhardt
2015-07-10 17:24                 ` OpenStack and GuixOps Ludovic Courtès
2015-06-01 15:18           ` Guix "ops" Pjotr Prins
2015-06-01 16:49             ` Thompson, David
2015-06-01 19:35               ` Guix deploy (and replace Puppet/Chef) Pjotr Prins
2015-07-10 16:37           ` Guix "ops" Christopher Allan Webber
2016-10-16 23:36           ` Christopher Allan Webber
2016-10-17 14:51             ` Ludovic Courtès
2016-10-19 21:10               ` Christopher Allan Webber
2016-10-20 13:29                 ` Ludovic Courtès
2016-10-20 17:01                   ` Christopher Allan Webber
2016-10-20 19:41                     ` Ludovic Courtès
2019-02-11 13:31 ` It's time to build "guix deploy" Christopher Lemmer Webber
2019-02-11 14:02   ` Pjotr Prins
2019-02-11 14:47     ` Christopher Lemmer Webber
2019-02-11 18:11       ` Amirouche Boubekki
2019-02-11 14:57     ` Christopher Lemmer Webber
2019-02-11 15:25       ` Pjotr Prins
2019-02-11 16:58   ` Thompson, David
2019-02-11 20:49     ` Ricardo Wurmus
2019-02-13 19:04       ` Giovanni Biscuolo
2019-02-14  7:14         ` swedebugia
2019-02-14  8:17           ` Pjotr Prins
2019-02-14 15:35             ` Giovanni Biscuolo
2019-02-14 16:55               ` Pjotr Prins
2019-02-14 14:17           ` Giovanni Biscuolo
2019-02-17  8:41             ` swedebugia
2019-02-17 15:42               ` Giovanni Biscuolo
2019-02-12 13:34     ` Christopher Lemmer Webber
2019-02-12 14:53       ` Thompson, David
2019-03-09 23:29   ` building " Thompson, David
2019-03-10 17:42     ` Ludovic Courtès
2019-03-11 14:41       ` Christopher Lemmer Webber
2019-03-12 13:08         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vbgdy6x8.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=dthompson2@worcester.edu \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).