Hi :) ons 2019-02-13 klockan 20:04 +0100 skrev Giovanni Biscuolo : > > > Ricardo Wurmus writes: > >> Thompson, David writes: >> >>> Other thoughts? >> >> Just for reference: to update Berlin build nodes I use this script: >> >> >> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/install-berlin.scm >> >> It˙s not great, but it˙s been helpful. > > thanks for sharing! (even if I can still barely understand what your > script does) I understand most parts of it ;) It is a real beauty and a testiment to the power of Guix and Guile. > > actually mainenance.git is full of treasures :-) > >> Berlin consists of a head node and many almost identical servers. > > AFAIU remote servers could be completely different each other for your > script to do its job, or am I missing something? Besides the host-ips being hardcoded and the (berlin-build-machine-os) procedure from (sysadmin build-machines) and the keys from (sysadmin people) it seems pretty generic. Ricardo, is (define (reconfigure-remote id guix-directory) dead code that could be commented out/removed? > >> To >> update one or more servers I run the script on the head node, which >> generates operating system configuration variants for each of the >> requested servers, builds the systems (offloading to all of the >> connected build nodes), copies the system closures to the target >> systems, and then runs ´reconfigureĦ on the targets. > > explained this way seems easy :-O > >> Since the operating system configuration record cannot be >> serialized, > > is there any plan or wip on this kind of serialization? > >> the build nodes need to have a copy of the code that˙s used to >> generate >> the operating system configuration. Not great. (They only need it >> to >> run ´reconfigureĦ; they wouldn˙t need that if >> ´reconfigureĦ could >> operate remotely.) > > "just" having a "guix system reconfigure --host " > would be a *huge* feature Agreed, but we would need to supply both keys and generic-config to this command as well. > >> Anyway, I thought I˙d share this with y˙all. > > IMHO your remote host configuration technique deserves a dedicated > blog > article... but I've already asked too much :-) Good idea!