From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Guix deploy (and replace Puppet/Chef) Date: Mon, 1 Jun 2015 21:35:51 +0200 Message-ID: <20150601193551.GD23504@thebird.nl> 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=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzVVQ-0001a5-5J for guix-devel@gnu.org; Mon, 01 Jun 2015 15:36:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzVVL-0004cY-6F for guix-devel@gnu.org; Mon, 01 Jun 2015 15:36:16 -0400 Received: from mail.thebird.nl ([95.154.246.10]:39604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzVVL-0004cU-0d for guix-devel@gnu.org; Mon, 01 Jun 2015 15:36:11 -0400 Content-Disposition: inline In-Reply-To: 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: "Thompson, David" Cc: guix-devel , Carlos Sosa (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 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.