unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: guix-devel@gnu.org, guix-sysadmin@gnu.org
Subject: Re: Solstice infrastructure hackathon
Date: Sat, 18 Dec 2021 17:08:36 +0100	[thread overview]
Message-ID: <87pmptripf.fsf@elephly.net> (raw)
In-Reply-To: <87r1abejke.fsf@gnu.org>


Mathieu Othacehe <othacehe@gnu.org> writes:

> We should clearly host some services such as the Guix website on
> Berlin & Bordeaux to bring some redundancy. However, as far as
> substitutes building is concerned, redundancy is premature when
> maintaining a single system, with our limited human and hardware
> resources, proves to be so complex.
>
> What do other people think?

I have a very unqualified opinion, which is directly related to the fact
that I’m interacting with ci.guix.gnu.org (and the software on it)
daily, but I have no idea what bordeaux is running.  I never contributed
to the build coordinator, never configured it, never fetched substitutes
from there either.

So to me the practical value of Cuirass as it exists now is quite
obvious, because I’m pretty familiar with it, have run an own instance
in the past, and many of our services (like the aforementioned installer
images) depend on it.

I feel strongly that maintenance and improvements to Cuirass should not
fall exclusively on Mathieu’s shoulders, so it would be wonderful if we
had more people hack on Cuirass.  That said, I don’t see exploratory
work on an alternative way to build substitutes as a redirection of
resources that would be needed elsewhere.  Motivation is not fungible.

The existence of these two systems affects our resources in that build
machines are added exclusively to either one or the other system.  This
has primarily implications for our limited aarch64 build nodes.  For
x86_64 we’ve got the vast majority connected to ci.guix.gnu.org.

Personally, I consider the continued development and improvement of
Cuirass to be essential.  When it comes to scarcity of build nodes I
think the solution should be to buy more.

-- 
Ricardo


  reply	other threads:[~2021-12-18 16:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-16  9:46 Solstice infrastructure hackathon Ludovic Courtès
2021-12-16 11:30 ` zimoun
2021-12-17  1:57 ` Christopher Baines
2021-12-17  8:12   ` Mathieu Othacehe
2021-12-18 16:08     ` Ricardo Wurmus [this message]
2021-12-20 22:58     ` Ludovic Courtès
2021-12-18 10:57 ` pukkamustard
2021-12-22  0:44 ` Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2021-12-16 10:13 Blake Shaw

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=87pmptripf.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guix-devel@gnu.org \
    --cc=guix-sysadmin@gnu.org \
    --cc=othacehe@gnu.org \
    /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).