Thanks Julien and Katherine

On Thu, 9 Sep 2021, Katherine Cox-Buday wrote:

> 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'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.