From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Lemmer Webber Subject: It's time to build "guix deploy" Date: Mon, 11 Feb 2019 08:31:03 -0500 Message-ID: <87h8da5u5k.fsf@dustycloud.org> References: <87k2wx6t1e.fsf@fsf.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:56921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtBg3-0006Ll-9m for guix-devel@gnu.org; Mon, 11 Feb 2019 08:31:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtBfy-00020j-0s for guix-devel@gnu.org; Mon, 11 Feb 2019 08:31:13 -0500 Received: from dustycloud.org ([50.116.34.160]:38878) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gtBfv-0001yP-Pm for guix-devel@gnu.org; Mon, 11 Feb 2019 08:31:07 -0500 In-reply-to: <87k2wx6t1e.fsf@fsf.org> 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" To: David Thompson Cc: guix-devel@gnu.org Hi, This has come up several times. A lot of us want "guix deploy". Personally, I'm running a variety of Debian servers and one Guix server and I am terrible at maintaining all of them. It's time for Guix Deploy... or it's time for me to give up and use something like Ansible + Debian. (Egads! I don't want to do that.) David's thoughts on this are below, and here's the original thread: Original thread can be found at the links below: https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00525.html https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00007.html https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00006.html There is a heavily, heavily bitrotted branch named "wip-deploy" where David originally started exploring these ideas. Conveniently, it's all in one commit: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy&id=fcd6fc84e493d05be1f7590ee77509c81ac315c2 That seems like a good starting point. But I know David feels that with real-world experience in devops type work that actually things would be a bit different than what's described in his original email. I'm not sure myself what would be different. It would be helpful to hear Dave weigh in on that point. Maybe Dave and I can meet up IRL now that we're close enough to each other to chat about it. But I know it's less fun than it used to be for Dave to consider this because now that's Dave's actual job... but all the more reason we need Dave's wisdom! :) David Thompson writes: > 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