[Top][All Lists]

[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 <> 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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]