Re: Shutting down qa.guix?

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]


Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> I am still planning to shutdown data.qa.guix.gnu.org and
>> QA which depends on it within the next couple of weeks. I do hope it can
>> return some point though, and hopefully sooner rather than later.
>>
>> On this like most decisions I'm indecisive, I could try and keep the
>> current server going, but it's not the most cost effective setup and
>> it's very low on disk space. I could replace the server with some
>> slightly better setup, but this would still mean I'm managing a key part
>> of the infrastructure, which is something I'm trying to move away
>> from. There was some discussion of the project taking over the hosting,
>> and maybe that will happen at some point, but it hasn't happened yet. So
>> while not having qa.guix.gnu.org for a time isn't ideal, I'm still going
>> with this approach.
>
> I think this underlines a collective failure to get our act together.
>
> I believe there’s consensus that qa.guix is useful and has been a boost
> for reviewers and contributors; we’d probably all want it to provide
> quicker feedback, which is a sign of success: we’ve come to rely on it.
>
> I know this has been discussed several times and it remains unclear to
> me why as a project we never managed to move forward—maybe the comfort
> of the status quo?

In addition, it's also unclear to me who should be making decisions on
things like this.

I also think that fundamentally I may think that processes and tooling
to make changes is more important than others regard it to be. While it
has no inherent value to users, personally I see it as so much more
important than actual Guix features or packages since the value to users
comes through Guix getting better faster, because of the increased pace
of changes and reduced number of regressions.

> Anyway, would it be possible for you to transfer billing of the hardware
> (Hetzner?) to Guix Foundation?  Does Guix Foundation know what it would
> cost them?

I believe so, at least I think that's possible. The costs have also been
discussed previously.

> The “spending committee” (Tobias, Ricardo, and myself), which oversees
> expenditure from the funds held at the FSF, can also be in the loop to
> provide additional financial support.
>
> As for system administration, is there documentation that people willing
> to help could look at?  Very concrete things like: what services are
> running on which machines, what do I do if one of them is stuck or if I
> get this error message, etc.

The configuration for beid, the machine that runs data.qa.guix.gnu.org
and Patchwork is in maintenance.git. It could probably use some more
comments to provide some context for the configuration.

There's also probably a benefit from making some high level architecture
diagrams for QA and the bordeaux build farm, and I can try and make a
start on these.

As for monitoring and responding to problems, that's a bit more
complicated, but in most cases a herd restart of the relevant bit will
temporarily resolve the issue. I'm still working on mitigating some of
the underlying problems that cause things to break.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]