From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: It's time to build "guix deploy" Date: Mon, 11 Feb 2019 11:58:46 -0500 Message-ID: References: <87k2wx6t1e.fsf@fsf.org> <87h8da5u5k.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:59732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtF9c-0001wm-Tb for guix-devel@gnu.org; Mon, 11 Feb 2019 12:14:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtEvE-0007Mr-59 for guix-devel@gnu.org; Mon, 11 Feb 2019 11:59:09 -0500 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:53537) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gtEvC-0007Ii-3q for guix-devel@gnu.org; Mon, 11 Feb 2019 11:59:06 -0500 Received: by mail-wm1-x331.google.com with SMTP id d15so18533613wmb.3 for ; Mon, 11 Feb 2019 08:58:59 -0800 (PST) In-Reply-To: <87h8da5u5k.fsf@dustycloud.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: Christopher Lemmer Webber Cc: guix-devel Hi Chris, Here we go again, eh? :) On Mon, Feb 11, 2019 at 8:31 AM Christopher Lemmer Webber wrote: > > 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. I have just a single Linode VPS that I can't be bothered to maintain most of the time. I would like to switch to Guix, as well. > 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 Wow, 2015. I was so young and full of hope then. ;) > 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 Useful for context, but the code can probably be tossed at this point. > 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. Sure, since 2015 I've become the lead devops person at my company, so I like to think I'm a bit wiser now. > 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! :) We could meet up IRL about this and I can try to make an earnest effort to deal with this. I think what has stopped me in the past is the sheer size of this project, and maybe dramatically scaling down the scope will allow us to get *something* out the door. Here are some general use-cases I know about for deployments, roughly ordered from small scale to large scale, and least complex to most complex: * Managing a physical machine or two that have been given memorable names that you update in-place (home scale) * Managing a virtual machine or two that have been given memorable names that you update in-place (blog scale) * Managing a large number of virtual machines whose names don't matter that you update in-place (proto-cloud scale) * Managing a large number of virtual machines whose names don't matter that are replaced when there is an update (cloud scale) * Managing 1 or more clusters of physical machines (datacenter scale) * Managing 1 or more clusters of physical machines and virtual machines ("corporation with a datacenter that is moving some stuff to the cloud" scale) There are, of course, more scenarios to consider (haven't even touched upon things like a Kubernetes cluster), but this is enough to illustrate the point that is a great diversity in setups. How many machines are there? Are the bare metal, virtual machines, or a mix of both? In the case of virtual machines, are updates applied in an immutable fashion or not? If immutable, which technique (blue-green, rolling release, etc.)? It makes my head spin to think about all the use-cases. So... let's start small. Can we write a tool that handles in-place updates to machines (physical or virtual) whose name and IP address we know well (our special pet servers) without precluding the possibility of scaling up to more sophisticated architectures? This would address the "home" and "blog" scale items above, which is probably what most of the people actually using Guix today would want. I got stuck trying to do in-place updates to remote machines years ago, but that was before Ludo made it easy to connect to remote systems. Other thoughts? Yours in vaporware, - Dave