From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Baines Subject: Re: Prototype tool for building derivations Date: Sun, 26 Apr 2020 20:59:11 +0100 Message-ID: <87wo62m31s.fsf@cbaines.net> References: <87h7xh6ex1.fsf@cbaines.net> <874ktbs1mx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:52004) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSnQx-0003Vt-78 for guix-devel@gnu.org; Sun, 26 Apr 2020 15:59:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSnQt-0006BB-Ov for guix-devel@gnu.org; Sun, 26 Apr 2020 15:59:20 -0400 In-reply-to: <874ktbs1mx.fsf@gnu.org> 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-mx.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > Hello! > > Christopher Baines skribis: > >> In terms of getting to a point where Guix packages build reliably and >> reproducibly, I think more testing is what's going to help. By taking >> packages and building them more, on a wide variety of hardware and >> software configurations, we'll get data on what works, what doesn't, and >> where improvements and fixes can be made. >> >> It's very much a prototype, but I've pushed some code up here [1] now, >> the README.org file [2] contains usage instructions as well as a >> description of the architecture. >> >> 1: https://git.cbaines.net/guix/build-coordinator/ >> 2: https://git.cbaines.net/guix/build-coordinator/about/ >> >> So far, I've mostly done the boring stuff, but I'm excited about what >> this could support. > > Neat! I like the architecture and the fact that it=E2=80=99s easy to tra= ck down > what was built and where. (guix scripts offload) currently doesn=E2=80= =99t save > that info. Thanks :) > A note about the usage as explained in the README: be sure to register > GC roots for derivations before passing them around processes. :-) Yeah, there's a lot to be desired in terms of this kind of polish. > Having an HTTP interface is really nice (I recently had someone ask > whether one could coordinate offloading over HTTP rather than SSH, this > is helpful in some contexts.) > > That also makes me wonder whether we could implement some of the store > RPCs over HTTP (I think Nix does something along these lines for > substitutes nowadays). Because the coordinator interface is in fact > close to a subset of the daemon=E2=80=99s RPC interface. I have been thinking about accessing the daemon using HTTP, however I'm still not sure if this would be better as a core feature, or a bridge that talks to the daemon on one end, handles authentication and talks HTTP on the other. ... >> I think it would be good to get point where there are many different >> individuals and groups providing independent sources of Guix packages, >> such that users can have a high level of confidence that the substitutes >> they're getting correspond to the source code. Getting there will be >> easier if substitute servers are easy to operate, and part of that I >> think comes down to how easy it is to see what's going on. With the >> current daemon implementation, I'm not sure how to get much data out >> (this could be possible, I haven't looked very closely). This approach >> however where the scheduling is done outside the daemon makes the >> information more accessible. > > That=E2=80=99s a worthy goal! I=E2=80=99m not sure the coordinator is ne= cessarily > helping directly there, because it=E2=80=99s another component (or two!) = to set > up, in addition to =E2=80=98guix publish=E2=80=99 and something like Cuir= ass that > monitors a channel and builds it. Indeed, there's a real risk in solving problems by building new things. One thing I've been thinking about with the build-coordinator is that it would be neat if it was easy to build around and extend. So I've added some "hooks" which mean you can just add Guile code that runs when builds succeed/fail or when an input can't be found. I've been experimenting in the last few days with adding the necessary options to the build-coordinator so that it can be used to build things for providing substitutes. This is in the form of some options in the build-coordinator, a script [3] to query data.guix.gnu.org for derivations (this has downsides, but it was a simple place to start) and a build-success hook [4] that performs a similar function as guix publish, but without a daemon, just moving the nar file in to the right place, and generating a corresponding narinfo file. 3: https://git.cbaines.net/guix/build-coordinator/tree/scripts/guix-build-c= oordinator-queue-builds-from-guix-data-service.in 4: https://git.cbaines.net/guix/build-coordinator/tree/guix-build-coordinat= or/hooks.scm?id=3D43312f9d977aac0f35bc5ce9b63e81cd5116d980#n46 Now this approach is far less mature than Cuirass + guix publish, but I think it has some advantages such as not requiring everything you want to provide substitutes for to be in a single store. Additionally, while you don't get the file level deduplication when you have compressed nar files, I think that this approach will reduce the disk space requirements compared to Cuirass + guix publish, as I think you'd probably have the compressed nar plus the item in the store in that case. > However I think it could be a way to restructure (guix scripts offload) > and/or Cuirass: they could talk to the coordinator instead of doing > their own thing. That's an interesting idea. > In fact, I think it would be quite easy to reimplement (guix scripts > offload) using the coordinator (see =E2=80=98process-request=E2=80=99 for= the protocol > with the daemon), and it would be interesting to see how that works. Yeah, I'll take a look. >> I think some of the design decisions here are quite short sighted. I >> think it would be better if some of this functionality could be handled >> by the guix-daemon, especially things like providing information on >> builds that are going to happen, but haven't happened yet. Once there's >> a Guile implementation of the guix-daemon, hopefully some of this >> technical debt can be repaid. > > Yup! > > Lots of food for thought! :-) Indeed :) Thanks, Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl6l6A9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9XctQw//Y7bY5P1T9LJIqQ/eEhMarX95Mvnf5RTALfgnMWNwfMXhxG6bc6AKCag2 yfJVirLbD7MChcvBUVj03JwFti0zf1v7LhzxCz7ohCHgWX82Q816faQDrdGFR8vF dceT3V+RxXsj34JSdFC/bd8aSu7iVjDru3GsWj0TmpErGrR0CV4x2GXa5ZiWcDzH 3T/qvlsavmFjNkKXMeHWuGwKIpwvfInF0u06STweExgE5VpKzZDv71zdrP8rWWIw scqDZfTBS7Xgm64nWfg+hqWoEa15C554tMtzjQF3XhlbHRs3RixZEYUlEsu7OJFq G2ZNSQBRzLASM7UuStFq/WIxdGcDSbTyn56mKnaEx/jkP8jXVzu6Wjt5RT6+i0Xi Kf3N0+qOtAY9U5wodgXnXrZdCFhuhC/oPmkIyr4NzJN6KY3Q1ef9iVyVxcMBwE3c Qm/nV7FpAgz/S2oYiYUKZOm6zPUH2afrqp/3HQqmxJtBhlctmMZ1AjSosZzpOH+/ iS3Yq0d8p172ia3VOzbrnO/1viFydE0CtvG83dWyI9M7eEROC6vViv03Gdw7YKQt l/yxzda2f7+ge58DRXzYeNcIZYHic/SMNLVJyJ/lrUQyPnE+YlhpD2e3QXA14EP5 sNZ4hSpghJbGPT2h7tH2IV7xPZKSvxGi0EAI5qzmXlrkzFJ5riw= =SFro -----END PGP SIGNATURE----- --=-=-=--