From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id mIBqHUHRj2AKSAEAgWs5BA (envelope-from ) for ; Mon, 03 May 2021 12:32:33 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id cH8pGUHRj2CbJgAA1q6Kng (envelope-from ) for ; Mon, 03 May 2021 10:32:33 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E30E1163ED for ; Mon, 3 May 2021 12:32:28 +0200 (CEST) Received: from localhost ([::1]:45626 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldVsJ-0007S0-QR for larch@yhetil.org; Mon, 03 May 2021 06:32:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldVqN-0005qA-Ri for guix-devel@gnu.org; Mon, 03 May 2021 06:30:27 -0400 Received: from mira.cbaines.net ([212.71.252.8]:53618) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldVqL-0002kM-At; Mon, 03 May 2021 06:30:27 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:8ac0:b4c7:f5c8:7caa]) by mira.cbaines.net (Postfix) with ESMTPSA id 8C99F27BC81; Mon, 3 May 2021 11:30:22 +0100 (BST) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 64621804; Mon, 3 May 2021 10:30:21 +0000 (UTC) References: <878s4ye116.fsf@cbaines.net> <87eeeo24a9.fsf@gnu.org> User-agent: mu4e 1.4.15; emacs 27.1 From: Christopher Baines To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: Bringing substitutes from the Guix Build Coordinator to users In-reply-to: <87eeeo24a9.fsf@gnu.org> Date: Mon, 03 May 2021 11:30:19 +0100 Message-ID: <87r1iocdok.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=212.71.252.8; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1620037949; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=L4SCZYVVo/kHAnMpnitgoWZRlwNrOwaU9m+m9IizvRU=; b=jLphrfg0kT+M3jvWtNHTVis7auZaWWTBhuv47LfOMLduNp/C3s45nvBuyJmz73Dr+u0m1A kGsqhg2kLpAqPElBEZXVDfstWtUxRFf9Ca6OICOA7al4R3Icw0w4klcbK+k66BkyeAirJn MfGP12FnMLl3Lsi213jVPxWyPDh0ek+BOl7vv4JPmZVoDx1y4RL8ES1kWS+1FoyORCtq/9 GUyfc8wbbcRoRiq2fMB0NzWPqUNA8cgExWzniQ53wq48sulsd9UFJH/DrsvnU6vlHTUnCY EFyqZUQIEQ7Dc2ZOY1CWMXVF07KiZCXk2szO7V1qsLT7pFyPsdcWVxGVRJ6Gsw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1620037949; a=rsa-sha256; cv=none; b=VEgvI/NXlO6zovc1ynKpNsEcfqOHagz2nKobHw9zCOWgqJQK993REZc5VL5snt83IgeBf3 bfAWhTeXjjjMISgAyk7xPmg61dnrtFBJN2v9ifU+TyZ7ThRKSp6xQsuGTPCi9+qcU45+Ru pu7banEhanQF0Mxwm9AZc3fk+cfShtYUfHQIRh/0q0Jq66mHW4SQWchGhi9ERsA4qAPKPx ydSy1OOd2U3aiMl5X2EUn8tDYEoSEyjg6quTOrd658wxlaJumsD5N8cVjoPmh4M6a8v0cK UtttiFI4TEhTU+TFqzRymJlgXk1uT55zUguR2bkJ9MQroTkuzbTVDJMM5xtUmQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -4.56 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: E30E1163ED X-Spam-Score: -4.56 X-Migadu-Scanner: scn0.migadu.com X-TUID: jb/VLoREecl4 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > Thanks for your message! It=E2=80=99s great to see a summary of what=E2= =80=99s been > cooking in the Coordinator and your vision around it. > > Christopher Baines skribis: > >> More specifically, while the architecture is similar to daemon >> offloading, there are some practical advantages. Since the switch to >> Cuirass remote workers for ci.guix.gnu.org, the advantages of building >> things across multiple machines in a coordinated manor have also become >> clear. Additionally, there are things that the Guix Build Coordinator >> enables, like automated retries, with the option to target specific >> agents, which can help with avoiding issues with non-reproducible >> failures, as well as helping to avoid issues when mixing QEMU emulated >> and native builds. > > These are nice examples of current QA blind spots that would be nice to > address. > > [...] > >> This is a topic I haven't got directly involved in, until now. I'm just >> a volunteer, in some ways the most involved I am is that I host an idle >> ARM build machine, I don't have any particular connection in the default >> approach to substitutes for users, or the hardware currently >> involved. > > It would be great to have that OverDrive plugged in behind ci.guix > because we=E2=80=99re still short on CPU power for ARM. (Not great we had > forgotten about this one!) > > It could be reconfigured with a config similar to > , > with a different host name and IP. We can discuss the details in a > separate thread and/or on guix-sysadmin, let me know! It was/is being discussed, the relevant thread is here: https://lists.gnu.org/mailman/private/guix-sysadmin/2021-March/003487.html >> However, I think some of the stuff I've been working on could be >> helpful, as I say, I think the Guix Build Coordinator is a step >> forward in terms of building things for substitutes, and that shows in >> the substitute availability percentages. >> >> Is there still a path to bring some of these benefits to users, and if >> so, what things need doing? > > My understanding is that, to build substitutes, we need more than the > Coordinator; we also need something to perform evaluations, similar to > the =E2=80=9Ctop half=E2=80=9D of Cuirass and the Data Service, right? H= ow would you > envision setting it up? The queue builds script bundled in with the guix-build-coordinator seems to work fine, that's how bayfront is currently set up: (service guix-build-coordinator-queue-builds-service-type (guix-build-coordinator-queue-builds-configuration (systems '("x86_64-linux")))) https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.= scm#n781 > To me, the way forward is not necessarily substitutes; it could be QA, > as you showed that it has helpful features. You already have access to > bayfront and it=E2=80=99d be great to experiment there. Do you have idea= s on > how to do make progress on that front? Ideas yes, and the two things are interrelated, but my perspective at the moment is that it'll be harder to try and get some value from the Guix Build Coordinator in terms of quality assurance, as compared to substitutes. > Besides, I feel that the Data Service has a huge role to play with a > variety of applications, including QA, but also way beyond as you showed > in the blog post=C2=B9. I think it=E2=80=99s time take advantage of it. = :-) > > Specifically, as far as QA is concerned, I think we should place the > Data Service at the center of the stage. It already does things that > Cuirass cannot and will not do, notably: linting, challenging substitute > servers to estimate reproducibility, and recording the history of all > this. Couldn=E2=80=99t it gather these other QA metrics mentioned above, > possibly from a Coordinator-powered bayfront? To me, linting and substitute comparison are less important quality assurance things. I think the key issues are around testing packages and things like system tests. There's been some progress, albeit slow progress with the patch testing setup I've been working on, but I've been viewing that as a way to test branches as well. Given changes happen through patches and branches, I think this makes sense, and I think the Guix Data Service has some nice features for helping with this, like comparing two revisions and working out what breakages have occurred. However, with patches and branches, this is very much a continuous integration tooling issue, much more than substitutes. Cuirass is already building branches, and it's been gaining features previously found in the Guix Data Service, like tracking the history of which derivations relate to which revision, and separating out packages from system tests so that it's easier to look at them. As people are going to Cuirass to look at the build status for packages, system tests and various branches, the problem is similar to that of substitutes. It doesn't matter if the Guix Build Coordinator seems to do some things better, when the question comes up about whether something has built yet, or whether a branch is ready to merge, Cuirass on ci.guix.gnu.org is where people are going, and that seems unlikely to change (at least less likely than the setup for providing substitutes). The Guix Data Service in the center, making it easier to do various things by providing the data, this was the idea when it started, but the reality recently is that strategy hasn't been paying off. > What I=E2=80=99d love to see is a set of =E2=80=9Cskins=E2=80=9D for the = Data Service: > purpose-specific interfaces to the service. There=E2=80=99s already the > reproducibility one, the one for package versions, etc. It would be > great to have a qa.guix.gnu.org entry point with a simplified interface > that would only show (say) reproducibility data, lint warnings, and so > forth. (Then we can also think of other skins, like Guix Weekly News, a > page dedicated to browsing package version history, a security-related > page, etc. But now I feel like a spoiled kid asking for yet more > presents. :-)) Haha, some QA entry point has come up before [1], but I haven't got around to looking at implementing anything yet. 1: https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00096.html --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmCP0LtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XcPNA/8CoUN/O/l+1RVtRmYh9CJUTfRknx+XMGD WFLsyx2TmHD7ixZj8V1KFLv7hJDXlBh8r1cdLfMgDad1d3tyxXSpsk4SqHi0hYLR 6E9kpPyVstUCnNZieySjaVfxdCm3937umDZRXpb7squu4mpyR1ObnOWmPGyo2i89 0Ct80K/2mi5Hfhps2pfano2tu2DjevlNZtwDkl/TWNMCLFAEVcsBzY7gR+p5mrwb Rxc0tgk83rLzIm2jiLiir5NnwaUtlXZvYgIdpekS2i3BrmI1LSdpL6IkQ22E/Ayr NDHhZ2qVxqhTzJ3V6EJ6BXc0Ryq7YAp+Zf3g20LN6aW84mhdBkh7DsoY5Ap5W5wp 5gmjErdx5H1prVV5DPMmb6/g5uuncSPx3A87RTJmYn9asl2gQ7Ix57AeofqSDpI6 Kk4SyE5WMeC24N0QtlFCDHXOJ2zLVicEbqFLyEqLLPpjUNCTwtBMiBtaqjukbBu7 A4/N/kwIGKyIzW4gbyXgRloXkvpYrsV6vzqiXL1xHdW5rrfjQprai/TPSpbvubUG b6Qi17JHkDpBhmm5swFL3E4mFuRvGJ+hUQCbMlHcU3N7W8ep/8wcgviHiG4ppCRo RG2oJB7GHQT+o23e8Vm4jShqQJCXNXyXuPvxRYD70q6yYkC5AOW9i74HcUnjuM2M j6k59m51YVI= =SpeA -----END PGP SIGNATURE----- --=-=-=--