Re: Sniping "guix deploy"

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

Jack Hill <jackhill@jackhill.us> writes:

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

Yeah, good point. There are probably a lot of other primitives here
worth implementing. I incorrectly scoped my statement to the
threat-model given.

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

Maybe a blanket #t could mean "leave this alone" when specified for an
operating-system field?

> Late night brainstorming is fun.

That it is! And though this discussion is fun, I think it's very
premature. There are a handful of bugs[1] open for deploy. One is
critical[2], and I just filed one[3] because deploy can share
state/provinance between all machines deployed together. And I'm not
sure if it has someone actively working to make it better?

As always I find myself wishing I had more time to contribute.

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

I am very fond of "trapdoors" in systems which are constrained/rigid by
design. It gives you all of the benefit of the constraints, but leaves a
way for users to work around bugs, or play with things until they get it
right and can bring it back into the fold.

[1] - https://issues.guix.gnu.org/search?query=%22guix+deploy%22+is%3Aopen
[2] - https://issues.guix.gnu.org/46756
[3] - https://issues.guix.gnu.org/50468

-- 
Katherine