[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix "ops"
From: |
Thompson, David |
Subject: |
Re: Guix "ops" |
Date: |
Mon, 1 Jun 2015 12:49:31 -0400 |
Hey Pjotr,
On Mon, Jun 1, 2015 at 11:18 AM, Pjotr Prins <address@hidden> wrote:
>> There's also unanswered questions like: How should we keep track of
>> state? How do we reconfigure already deployed machines? How do we shut
>> down a deployment and unprovision the resources it used? Basically, how
>> many hooks does the <platform> record type need to cover everything?
>
> The current 'deploy' basically generates a machine from scratch -
> there is some similar funtionality in Nix. I read the code and it is
> pretty simplistic for now which is possible when you generate a
> machine once.
Yes, the code is simplistic because I have only spent about a day or
two actually writing code for it. You'll notice that the <platform>
data type has many of its fields commented out. Much work to do.
> What I would like to have is a state-machine that can be rerun within
> an installed deploy in the vein of Puppet/Chef/cfengine but without
> the complicated setup of a client/server model (the server 'model'
> should simply be a git repository with branches).
For persisting state between 'guix deploy' runs, I was going to write
an s-expression to a file. The exact state written to such a file and
how it will be used will be defined by <platform> objects. The state
could then be synced among all the workstations that are doing
deployments via whichever mechanism you prefer. I would like to use
Git, too, but I don't 'guix deploy' to be concerned with such details.
> That means that after 'deploy' we can run the state and it
> checks/updates files that may have been changed. I use something like
> that to run my hosts.allow configuration (for example). When I want to
> add an IP address, I change the state and rerun 'deploy'. In the past
> I used to run cfengine. Later I wrote cfruby/cfenjin which I still run
> today for deployment and updates. For me it is time to write something
> that plays well with GNU Guix.
>
> 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. 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.
> 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?
- Dave
- Re: Guix "ops", Pjotr Prins, 2015/06/01
- Re: Guix "ops",
Thompson, David <=