Re: It's time to build "guix deploy"

[swedebugia]

Hi :)

ons 2019-02-13 klockan 20:04 +0100 skrev Giovanni Biscuolo <address@hidden>:

Ricardo Wurmus <address@hidden> writes:

Thompson, David <address@hidden> 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!