GNU bug report logs - #48435
[PATCH] Start enabling substitutes from bayfront.

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: guix-devel <at> gnu.org, Andreas Enge <andreas <at> enge.fr>, 48435 <at> debbugs.gnu.org
Subject: [bug#48435] Bringing substitutes from the Guix Build Coordinator to users
Date: Tue, 18 May 2021 23:24:36 +0200

Hello!

Christopher Baines <mail <at> cbaines.net> skribis:

> Christopher Baines <mail <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.