From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Thompson Subject: Guix "ops" Date: Mon, 27 Apr 2015 19:38:37 -0400 Message-ID: <87k2wx6t1e.fsf@fsf.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmshG-0002w1-9o for guix-devel@gnu.org; Mon, 27 Apr 2015 19:44:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ymsbn-0004YM-6d for guix-devel@gnu.org; Mon, 27 Apr 2015 19:38:40 -0400 Received: from mail.fsf.org ([208.118.235.13]:34296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymsbn-0004YH-3H for guix-devel@gnu.org; Mon, 27 Apr 2015 19:38:39 -0400 Received: from 209-6-40-86.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.40.86]:44773 helo=izanagi) by mail.fsf.org with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Ymsbm-000852-Rd for guix-devel@gnu.org; Mon, 27 Apr 2015 19:38:38 -0400 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: guix-devel@gnu.org Hey folks, I'm writing this in an attempt to "think out loud" about a deployment automation tool for GuixSD. Guix needs a NixOps[0] equivalent. NixOps is the Nix project's deployment automation tool. I read the source code[1] a bit, and here's what I've learned about it: * The central data type is a "deployment", which is a Nix expression consisting of one or more named OS configs * The OS configs contain extra data that specifies the target platform: VirtualBox, EC2, NixOS container, etc. Each platform implements the generic MachineDefinition and MachineState interfaces. * The 'nixops' command is stateful. It stores necessary state about deployed systems in a special directory ($HOME/.nixops by default), such as the IP addresses of the deployed systems. Because of this, each deployment needs a unique identifier. * Deployments may be parameterized by values known only at deploy time. This covers cases such as a web application server needing to know the IP address of the database server. * There are useful subcommands to check the status of each system or ssh into one of them. Here's a rough outline of how I'm thinking of implementing similar features in Guix: * Introduce new data types: * : The generic interface type for implementing deployment targets. Its fields hold procedures for various actions like 'provision', 'destroy', 'boot', or 'reboot'. I haven't determined the precise list of actions needed, but it will become apparent as platforms are added. * : Describes a single system in the deployment. Contains a name string, an , and a . * : Contains a name string and a list of and procedures. Procedures in the list should accept an argument containing the deployment results of the non-parameterized machines and return a . * Use a simple s-exp deployment state format. Store the state in $HOME/.config/guix by default. * Implement a 'guix ops' subcommand roughly the same actions as NixOps: create, deploy, start, stop, destroy, list, info, check, ssh, etc. * The bulk of the work will be creating objects that actually provision various types of resources. For prototyping, a 'local-vm-platform' would be enough to test that the whole system works. Anyone want to join in on this brainstorming party? Your thoughts are appreciated! [0] http://nixos.org/nixops/ [1] https://github.com/NixOS/nixops -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate