[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sniping "guix deploy"
From: |
Katherine Cox-Buday |
Subject: |
Re: Sniping "guix deploy" |
Date: |
Thu, 09 Sep 2021 23:06:53 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Julien Lepiller <julien@lepiller.eu> 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.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!
--
Katherine