1. 20
  1.  

  2. 2

    It’s not clear to me from the article what guix deploy actually does. I assume it merely sshs into a machine to run guix system reconfigure, while providing the appropriate system configuration. But does it (will it?) deal with “atomically” reconfiguring the cluster, so that all instances run the new versions, or none do, if something fails in between? Does it deal with restarting services? (I was surprised to learn that guix system reconfigure only changes the file system side of things, it doesn’t appear to deal with e.g. getting the cron daemon to read its updated configuration.)

    As an aside, I’m curious: Is the explicit looping construct at the end of the source snippet idiomatic scheme code? From a functional point of view, I’d have expected a map over a range of numbers.

    1. 6

      It’s not clear to me from the article what guix deploy actually does.

      It’s a bit late to update the blog post now, but considering that we give a similar explanation in the manual, this is very useful feedback.

      I assume it merely sshs into a machine to run guix system reconfigure, while providing the appropriate system configuration.

      You can certainly think of it like that. In fact, the patch series I’m currently working on unifies the code between guix deploy and guix system reconfigure. The process of deployment is a bit more complicated since you can’t “just” send send the appropriate system configuration over the wire, and guix deploy does more than activate a new generation on a remote host; the tool builds what we call an “operating system closure” on the host, meaning that declarative components of the system configuration can stay on the host and only the outputs need to be sent over.

      But does it (will it?) deal with “atomically” reconfiguring the cluster, so that all instances run the new versions, or none do, if something fails in between?

      That’s what we’re working on right now. We’re running through a couple options for treating a deployment as atomic (and, specifically, handling failures). If you’d like to share any comments or suggestions, the conversation is taking place on guix-devel.

      Does it deal with restarting services? (I was surprised to learn that guix system reconfigure only changes the file system side of things, it doesn’t appear to deal with e.g. getting the cron daemon to read its updated configuration.)

      That’s also something we’re working on; we’re waiting for a restart-strategy field for Shepherd services to be fleshed out. Then, both guix deploy and guix system reconfigure will restart services when it makes sense.

      As an aside, I’m curious: Is the explicit looping construct at the end of the source snippet idiomatic scheme code? From a functional point of view, I’d have expected a map over a range of numbers.

      Probably not :] I’ll admit that I’m a Common Lisp-er dipping his feet into Scheme territory, and I haven’t gotten to the part of SICP that describes streams.

      1. 3

        Thanks for the detailed answer, sound great!

      2. 2

        I would consider it idiomatic, save for the fact I’d count down instead so the resulting list is in order. IMO there’s no point allocating a new list or stream just to immediately deconstruct it.