From mboxrd@z Thu Jan 1 00:00:00 1970 From: swedebugia Subject: Re: It's time to build "guix deploy" Date: Thu, 14 Feb 2019 08:14:15 +0100 Message-ID: <1550128455.8914.0@mail.riseup.net> References: <87k2wx6t1e.fsf@fsf.org> <87h8da5u5k.fsf@dustycloud.org> <87y36mjbjo.fsf@elephly.net> <87y36jcxxj.fsf@roquette.mug.biscuolo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=-T7qospVAo0zufIT4UJYi" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:50998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guBEc-0002fX-DA for guix-devel@gnu.org; Thu, 14 Feb 2019 02:15:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1guBEa-0007zF-Ok for guix-devel@gnu.org; Thu, 14 Feb 2019 02:15:02 -0500 Received: from mx1.riseup.net ([198.252.153.129]:37508) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1guBEa-0007fm-86 for guix-devel@gnu.org; Thu, 14 Feb 2019 02:15:00 -0500 In-Reply-To: <87y36jcxxj.fsf@roquette.mug.biscuolo.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Giovanni Biscuolo Cc: guix-devel --=-T7qospVAo0zufIT4UJYi Content-Type: text/plain; charset=iso-8859-13; format=flowed Content-Transfer-Encoding: quoted-printable Hi :) ons 2019-02-13 klockan 20:04 +0100 skrev Giovanni Biscuolo=20 : >=20 >=20 > Ricardo Wurmus writes: >=20 >> Thompson, David writes: >>=20 >>> Other thoughts? >>=20 >> Just for reference: to update Berlin build nodes I use this script: >>=20 >> =20 >> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/instal= l-berlin.scm >>=20 >> It=FFs not great, but it=FFs been helpful. >=20 > 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. >=20 > actually mainenance.git is full of treasures :-) >=20 >> Berlin consists of a head node and many almost identical servers. >=20 > 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=20 that could be commented out/removed? >=20 >> 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 =B4reconfigure=A1 on the targets. >=20 > explained this way seems easy :-O >=20 >> Since the operating system configuration record cannot be=20 >> serialized, >=20 > is there any plan or wip on this kind of serialization? >=20 >> the build nodes need to have a copy of the code that=FFs used to=20 >> generate >> the operating system configuration. Not great. (They only need it=20 >> to >> run =B4reconfigure=A1; they wouldn=FFt need that if=20 >> =B4reconfigure=A1 could >> operate remotely.) >=20 > "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=20 this command as well. >=20 >> Anyway, I thought I=FFd share this with y=FFall. >=20 > IMHO your remote host configuration technique deserves a dedicated=20 > blog > article... but I've already asked too much :-) Good idea! = --=-T7qospVAo0zufIT4UJYi Content-Type: text/html; charset=iso-8859-13 Content-Transfer-Encoding: quoted-printable
Hi :)

ons 2019-02-13 klockan 20:04 +0100 skrev Giovanni B= iscuolo <g@xelera.eu>:
Ricardo Wurmus <rekado@elephly.net= > writes:
Thompson, David <dthompson2@worcester.edu> writes:
Other thoughts?
Just for reference: to update Berlin build nodes I use this script: https://git.savannah.gnu.org/cgit/guix/maintenan= ce.git/tree/hydra/install-berlin.scm It=FFs not great, but it=FFs 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 serve= rs.
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 bu= ild-machines) and the keys from
(sysadmin people) it seems pretty generic.
<= span style=3D"white-space: pre-wrap;">
Ricardo, is (define (reconfigure-remote id guix-dir= ectory) 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 =B4reconfigure=A1 on the targets.
explained this way seems easy :-O
Since the operating system configuration record cannot be seri= alized,
is there any plan or wip on this kind of serialization?
the build nodes need to have a copy of the code that=FFs used = to generate the operating system configuration. Not great. (They only need it to run =B4reconfigure=A1; they wouldn=FFt need that if =B4reconfigure=A1 coul= d operate remotely.)
"just" having a "guix system reconfigure --host <remote-hostname/IP>" would be a *huge* feature

<= span style=3D"white-space: pre-wrap;">Agreed, but we would need to supply b= oth keys and generic-config to this command as well.

Anyway, I thought I=FFd share this with y=FFall.
IMHO your remote host configuration technique deserves a dedicated blog article... but I've already asked too much :-)
Good idea!
= --=-T7qospVAo0zufIT4UJYi--