unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jack Hill <jackhill@jackhill.us>
To: Katherine Cox-Buday <cox.katherine.e@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Sniping "guix deploy"
Date: Fri, 10 Sep 2021 01:07:47 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2109100042050.2109@marsh.hcoop.net> (raw)
In-Reply-To: <87v9393wgy.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3303 bytes --]

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.

  reply	other threads:[~2021-09-10  5:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 23:45 Sniping "guix deploy" Julien Lepiller
2021-09-10  4:06 ` Katherine Cox-Buday
2021-09-10  5:07   ` Jack Hill [this message]
2021-09-10 15:36     ` Katherine Cox-Buday

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2109100042050.2109@marsh.hcoop.net \
    --to=jackhill@jackhill.us \
    --cc=cox.katherine.e@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).