From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: Guix "ops" Date: Mon, 1 Jun 2015 12:49:31 -0400 Message-ID: References: <87k2wx6t1e.fsf@fsf.org> <87vbgdy6x8.fsf@gnu.org> <87fv7h5zhk.fsf@fsf.org> <87mw1obbfq.fsf@gnu.org> <87bnhzrjf1.fsf@gnusosa.net> <87382oejz8.fsf@fsf.org> <20150601151854.GA22738@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzSu8-0007JC-S1 for guix-devel@gnu.org; Mon, 01 Jun 2015 12:49:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzSu5-0003TW-MM for guix-devel@gnu.org; Mon, 01 Jun 2015 12:49:36 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:33003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzSu5-0003T2-GP for guix-devel@gnu.org; Mon, 01 Jun 2015 12:49:33 -0400 Received: by padj3 with SMTP id j3so47427973pad.0 for ; Mon, 01 Jun 2015 09:49:32 -0700 (PDT) In-Reply-To: <20150601151854.GA22738@thebird.nl> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Pjotr Prins Cc: guix-devel , Carlos Sosa Hey Pjotr, On Mon, Jun 1, 2015 at 11:18 AM, Pjotr Prins 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 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 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 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 objects is far more powerful than a primitive class labeling system. Hope this helps clarify some things. Thoughts? - Dave