Ludovic Courtès writes: > Christopher Allan Webber <cweb...@dustycloud.org> skribis: > >> - Should I build the entire derivation of the system I want to run on >> the remote machine locally first, then copy that over? (I assume >> this is possible, and eventually desirable, especially if doing >> mass deployments? But it might not be desirable in every case.) >> Would that use the substitute mechanism? > > Yes! :-) > > Essentially deployment would work like this: > > 1. Compute the system derivation and build it locally (i.e., on the > machine where ‘guix deploy’ is running.) > > As a user, you can choose to have offloading setup such that the > actual build will take place on (some of) the target machines, but > that’s completely orthogonal. > > 2. Send the derivation out to the target(s) that are real machines. > For targets that are local containers or VMs, there’s nothing to > do. > > 3. On targets that are real machines, perform the equivalent of ‘guix > system reconfigure’—i.e., update the /run/current-system symlink, > restart Shepherd services that can be restarted, etc. > > IIRC David was testing using VMs and containers as the targets (the > <platform> record¹) because it’s easier. > > Does that make sense? > > Hopefully David will correct me. :-)
Ok, it does make sense! It's nice to see the examples in the docs of exporting a system over ssh, even. Anyway, I played with "guix archive" this morning; it works well. So, sending an entire closure over the network: should be easy. I see that there's a --missing field; I'm a little bit unsure of how two machines would coordinate here though with the existing tooling... it doesn't look like we have a way to export the list of packges that --missing could then read in? And then you'd need to feed whatever --missing gave you back into --export I guess. Anyway, it does seem like this is the right direction! Exciting! - Chris > > Ludo’. > > ¹ https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00320.html