Re: Sniping "guix deploy"

[Katherine Cox-Buday <cox.katherine.e@gmail.com>]

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