From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id OL3cKEHoOmHpeQAAgWs5BA (envelope-from ) for ; Fri, 10 Sep 2021 07:08:17 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id uLzAJEHoOmFPdwAAbx9fmQ (envelope-from ) for ; Fri, 10 Sep 2021 05:08:17 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CF2493E96 for ; Fri, 10 Sep 2021 07:08:16 +0200 (CEST) Received: from localhost ([::1]:39782 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mOYlr-00017l-JC for larch@yhetil.org; Fri, 10 Sep 2021 01:08:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38886) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOYlV-000158-DH for guix-devel@gnu.org; Fri, 10 Sep 2021 01:07:53 -0400 Received: from minsky.hcoop.net ([104.248.1.95]:52424) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOYlT-0002TQ-IO for guix-devel@gnu.org; Fri, 10 Sep 2021 01:07:53 -0400 Received: from marsh.hcoop.net ([45.55.52.66]) by minsky.hcoop.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mOYlP-0005XI-LZ; Fri, 10 Sep 2021 01:07:47 -0400 Date: Fri, 10 Sep 2021 01:07:47 -0400 (EDT) From: Jack Hill X-X-Sender: jackhill@marsh.hcoop.net To: Katherine Cox-Buday Subject: Re: Sniping "guix deploy" In-Reply-To: <87v9393wgy.fsf@gmail.com> Message-ID: References: <20210910014504.77da1263@tachikoma.lepiller.eu> <87v9393wgy.fsf@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="925712948-1004468840-1631250467=:2109" Received-SPF: pass client-ip=104.248.1.95; envelope-from=jackhill@jackhill.us; helo=minsky.hcoop.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1631250497; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=pEhjncrXSEsG4UcjpzPHB6nWbiiK3CMxNb7+2tjMbbw=; b=XV3QSvx5uqOkxAXsolgdmJ9juj8q38L2mxt/fjZFRTpbGk2z+TuG1z/roIfGb9DGrymJJw WZAuV7QsuKZ7AC+Et5hHwhesiYvjdjeXyLoChxavsnH8xT2QfKq46IBTTIvRibi2BafRgi bAkihWPhtmcDVLples/E3NkRPISmxB8h1aLCxXGuvbvbMXwqx93wqBTidIyONidn3WFkbp xU9Xs4UZEQXGiCzJFWb91SX1+XIfafCkOGWzJfEFOxDNV9hQAKah5Ux54R3Y6KyFH59P6a yhuD2Ogpd8INUIvPKyQyJZwROTZqgpj9SRONfYmO0F9wbNpvAkOsBiY0CqXohQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631250497; a=rsa-sha256; cv=none; b=ExL37B7N2gvhmZqhNQMTP392sx0D1D+TalHxPzAxOKwWAw/EIfTT7DjLAC8nx4A6GzAQ5Z 5PZErTB/sUioQquGOvHYLqW2jMx1Tdhcz5c4rACfxCVBaKubvzfZRD1GROyC/FEdoA1Ujl SE6e0Tn0yfup51hP8po+TYMPtEZsXqVvbHIHt49SJxO5E6+cAd+1wIEv+WLUTZ6w8myG5h yyNMTNj3IM63NlGTprW3lEabNc0t1Bf2aDX4sJsNi+hpNMlC96xuHjeAzCDRe7p7H8uXm7 4tiQOBeZPB9eDnirapxodjJjqGtblQ3zBtr4hqvR7AgZ37QgEvtjIN6bwTe01g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.41 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: CF2493E96 X-Spam-Score: -1.41 X-Migadu-Scanner: scn0.migadu.com X-TUID: TJquznYjU+Ls This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --925712948-1004468840-1631250467=:2109 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Thanks Julien and Katherine On Thu, 9 Sep 2021, Katherine Cox-Buday wrote: > Julien Lepiller writes: > >> As a rule of thumb, when you update multiple systems and one system >> provides security for another, you should update the security system >> before the protected system if you restrict access, and the other way >> around if you allow more access. Maybe we could add that to the manual, >> in addition to letting users configure upgrade order? > > I am not a Guix deploy expert (although I have just begun using it -- > it's great!), but it seems to me that this is a higher-order mechanism > that wields deploy in a certain way. I'm also not a deploy expert, nor I have I finished reading Julien's paper, but I really like this idea of building mechanisms around guix deploy, so wanted to reply. Thanks for suggesting it. > I.e., as I understand it, deploy is going to walk the list of machines > you give it and run the deployment synchronously. If you wanted to build > references between machines, for security, live-upgrades, or otherwise, > I would think you'd declare some kind of data structure other than a > list (probably a graph) which would tell deploy what order to perform > the deployment. > > Rolling back is a whole other matter, but I imagine that same data > structure could tell deploy how to walk it in reverse. > > So, not that I have time to work on any of this, but what I would do is > shore up deploy so that it's nice and robust (I think it's still early > days), and then work on a declarative way to define machines and their > dependencies, and then a function to produce a sequence from these data > structures so deploy can stay an iterative type process. > > Just late night thoughts from me :) Thanks for the input! I know that CoreOS at one point took cluster-wide knowledge into account when performing upgrades (so as not to take down all replicas at once for instance). It and similar projects are probably too far afield to take implementation ideas from, but some of the high level concepts might be worth taking inspiration from. Another higher level mechanism that we might need for deploy is some way to do IO when building operating system definitions. Something along the lines of how "facts" are handled in the various configuration management tools. I see this as being useful for doing things like reconfiguring a system, but leaving the disk partitioning how it is now without having to to declare what the partitions are ahead of time.* In Scheme, there is nothing stopping us from doing IO at arbitrary points in an operating system definition, but as this takes away from the declarative nature of the configuration, having shared mechanisms for doing this in a clear, maintainable, and principled way could be very useful. Late night brainstorming is fun. Take care, Jack * I suppose file systems are the most obvious place where ugly state like this can sneak its way in since they are essential giant buckets to hold state, which is probably why this example has been running around in my head. While it might be nice to think about eliminating all state that doesn't seem workable, but maybe we come up with some way to represent the state declaratively à la Haskell's IO and State monads. --925712948-1004468840-1631250467=:2109--