Re: Organising Guix Days
We also have a devroom at FOSDEM 2022 (online). Last year was a great succes with many cool talks and a social during the day, see => https://archive.fosdem.org/2021/schedule/track/declarative_and_minimalistic_computing/ We still have slots for 2 or 3 speakers. If you are interested in talking about your work for 15 minutes and promote Guix do tell us this weekend. You can write Manolis, Julien, Oliver or me directly and we can see if it fits the day. Check out the existing talks for examples. There is no need to be shy - we are among friends. Pj.
Re: Solstice infrastructure hackathon
Mathieu Othacehe 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
Re: Solstice infrastructure hackathon
I'm in!
Ludovic Courtès writes:
> Hello Guix!
>
> This week, the node behind {ci,issues,disarchive}.guix.gnu.org and
> guix.gnu.org was down twice for a few hours—nothing terrible in the end,
> but it reminded us that, even though Guix doesn’t rely on any particular
> machine, we can definitely feel the inconvenience when it’s down.
>
> We were unlucky enough that it happened days after the other build farm,
> bordeaux.guix.gnu.org, ran out of disk space and had its CI stopped,
> right before the big merge—so it doesn’t have substitutes for current
> master.
>
> While discussing this on IRC the other day, we thought that perhaps it
> was time to have an infrastructure hackathon. How about Tuesday,
> Dec. 21st? (Probably with a followup in January.)
>
> Here are tasks that were brought up:
>
> • Set up a backup server for berlin.guix.gnu.org, the head node of the
> ci.guix.gnu.org, possibly moving some services such as the web site
> there.
>
> • Add DNS redundancy for guix.gnu.org so it can point to one of two
> hosts (need to figure out certbot challenges so both machines can
> update their certificates).
>
> • Set up status.guix.gnu.org with sysadmin status updates (possibly
> using Prometheus?).
>
> • Come up with a plan to add disks to the RAID array on bayfront, the
> head node of bordeaux.guix.gnu.org.
>
> • Work on a plan to back up the Disarchive database currently on
> berlin.guix.
>
> • Work on a plan to mirror nars from ci.guix and bordeaux.guix, using
> plain rsync or
