unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org, Andreas Enge <andreas@enge.fr>,
	48435@debbugs.gnu.org
Subject: [bug#48435] Bringing substitutes from the Guix Build Coordinator to users
Date: Tue, 18 May 2021 23:24:36 +0200	[thread overview]
Message-ID: <87wnrv68h7.fsf@gnu.org> (raw)
In-Reply-To: <87lf8bbzbl.fsf@cbaines.net> (Christopher Baines's message of "Tue, 18 May 2021 20:45:50 +0100")

Hello!

Christopher Baines <mail@cbaines.net> skribis:

> Christopher Baines <mail@cbaines.net> writes:
>
>> Is there still a path to bring some of these benefits to users, and if
>> so, what things need doing?

[...]

> Obviously just having the substitutes doesn't magically get them to
> users, so I've started looking in to the changes to start making that
> happen. Adding the signing key and changing the defaults in a few places
> seems like a good step forward [1].
>
> 1: https://issues.guix.gnu.org/48435
>
> I want to push on with this within the next couple of weeks, mostly so I
> can shift focus to Outreachy and the security related tooling work, but
> also because I still think this will be a good step forward in terms of
> substitute availability for users. It's been over a year now since
> implementation started, so it would be good to actually make a positive
> difference.

I’m fine with distributing an extra signing key alongside that of
ci.guix.gnu.org.

I’m unsure about having two substitute URLs by default since it adds a
bit of overhead, though that overhead is only upon cache misses (I have
that setup on my laptop actually).

It’s also a one-way change: people are likely to keep the defaults
“forever”.  So we can’t just “experiment” and change our mind later.
That means we should at least have a DNS entry that’s not tied to a
particular machine, like ci2.guix.gnu.org or whatever.

WDYT?

Now, what would be nice is to have a second build farm with the
K-out-of-N policy you mention in mind.

> There's a few issues still on my mind. Even though the substitute
> availability percentages are good when compared to ci.guix.gnu.org, as
> bayfront has much less compute power connected, it might not keep up as
> well when big sets of changes are merged. I think that's just an
> argument for using the build coordinator on berlin and the connected
> machines though.

As much as I’d have preferred a single solution in this area, fueling
competition between the Coordinator and Cuirass and their access to
official infrastructure doesn’t seem like a viable path to me.

I think the primary value in having a second build farm would be
reproducibility and doing away with the single point of failure.
Overall substitute coverage probably wouldn’t change much.

I agree with Mathieu that maintaining it has a cost, but maybe we can
try.

I realize I’m asking questions rather than providing answers, which may
be because I don’t see a clear path ahead.  :-)

Thanks!

Ludo’.




  reply	other threads:[~2021-05-18 21:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-01 18:56 Bringing substitutes from the Guix Build Coordinator to users Christopher Baines
2021-05-02 21:51 ` Ludovic Courtès
2021-05-03 10:30   ` Christopher Baines
2021-05-04  8:27     ` Ludovic Courtès
2021-05-04 19:22       ` Christopher Baines
2021-05-11 20:18         ` Ludovic Courtès
2021-05-04 18:38 ` Andreas Enge
2021-05-04 19:29   ` Christopher Baines
2021-05-12 22:58     ` Christopher Baines
2021-05-15 16:38       ` Ludovic Courtès
2021-05-15 17:24         ` Christopher Baines
2021-05-17 20:28           ` Ludovic Courtès
2021-05-18  8:26             ` Christopher Baines
2021-05-06 16:26   ` Ludovic Courtès
2021-05-18 19:45 ` [bug#48435] " Christopher Baines
2021-05-18 21:24   ` Ludovic Courtès [this message]
2021-05-18 22:29     ` Christopher Baines
2021-05-19  6:54       ` Mathieu Othacehe
2021-05-19  7:57         ` Christopher Baines
2021-06-07 14:53   ` Christopher Baines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnrv68h7.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=48435@debbugs.gnu.org \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).