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.
next prev parent 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.