[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Guix deploy (and replace Puppet/Chef)
From: |
Pjotr Prins |
Subject: |
Guix deploy (and replace Puppet/Chef) |
Date: |
Mon, 1 Jun 2015 21:35:51 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
(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.