Hi :)

ons 2019-02-13 klockan 20:04 +0100 skrev Giovanni Biscuolo <g...@xelera.eu>:


Ricardo Wurmus <rek...@elephly.net> writes:

 Thompson, David <dthomps...@worcester.edu> 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 <remote-hostname/IP>"
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!

Reply via email to