all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: "Thompson, David" <dthompson2@worcester.edu>
Cc: guix-devel <guix-devel@gnu.org>, Carlos Sosa <gnusosa@gnusosa.net>
Subject: Guix deploy (and replace Puppet/Chef)
Date: Mon, 1 Jun 2015 21:35:51 +0200	[thread overview]
Message-ID: <20150601193551.GD23504@thebird.nl> (raw)
In-Reply-To: <CAJ=Rwfa=DgwjRRjfuJ=UOU0HiFSt7EWEbJFb8gQhVoqoCU7nmg@mail.gmail.com>

(changed subject)

On Mon, Jun 01, 2015 at 12:49:31PM -0400, Thompson, David wrote:
> > Are you envisaging something like that? Something that reruns state
> > and updates? It is a lot more complicated because you need a way to
> > define state, modify files, allow for transaction and roll-back.
> > Ideally the system should execute in parallel (for speed) and be
> > ordered (i.e. if two methods change the same file the order matters).
> > BTW cfruby lacks transactions and parallel execution, we could start
> > without.
> 
> Sort of yes, sort of no.  What you are describing sounds quite
> imperative.  

Right.

> In Guix, if we were to re-deploy a configuration to a
> running remote system, we'd do the equivalent of what 'guix system
> reconfigure' does now for local GuixSD machines: an atomic update of
> the current system (changing the /run/current-system symlink).  'guix
> deploy' cannot possibly do a good job of managing non-GuixSD systems
> that just happen to run Guix.  I think it would be better to use the
> existing configuration management tools for that.

OK, this sounds exciting and could certainly work well. I guess
hosts.allow would be an input to an sshd builder, right, so different
configurations become their own subtrees in the store. I like that
idea. hosts.allow (as a complication) is actually part of tcp-wrappers
so it would have to be configured for all tools that it addresses on a
machine. I presume hosts.allow would be stored in the store too.

> > The first step is to define state by creating 'classes' of machines.
> > One class could be deploy 'sshd with IP restriction'. That would be a
> > good use case.
> 
> Are you proposing that we add a formal concept of "classes" in Guix or
> is this just to illustrate an idea?  If the former, I think that pure
> functions that return <operating-system> objects is far more powerful
> than a primitive class labeling system.
> 
> Hope this helps clarify some things.  Thoughts?

I am not too clear on the OS objects, but maybe I should play with
deploy first. I guess what you are saying is that a machine
configuration is generated by its s-expression(s) so we don't need
classes. Wherever these s-expressions come from is an implementation
issue. Right?

Pj.

  reply	other threads:[~2015-06-01 19:36 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
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               ` Pjotr Prins [this message]
2015-07-10 16:37           ` 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

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

  git send-email \
    --in-reply-to=20150601193551.GD23504@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=dthompson2@worcester.edu \
    --cc=gnusosa@gnusosa.net \
    --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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.