[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mid-December update on

From: zimoun
Subject: Re: Mid-December update on
Date: Wed, 15 Dec 2021 23:49:35 +0100

Hi Chris,

Thanks for the update.  And for the all work. :-)

On Wed, 15 Dec 2021 at 16:48, Christopher Baines <> wrote:

> In summary, the space issue I mentioned in the previous update has
> effectively been addressed. All the paused agents are now unpaused and
> builds are happening again.

The timing had almost been perfect. ;-)

Well, as discussed on Sept., one concern I have is about “long-term
storage” – where long-term is not well-defined and storage either.

Do you think that Bordeaux could run


?  Having a redundancy about all origins would avoid breakage.  For
instance, because Berlin was down yesterday morning, “guix pull” was
broken because the missing ’datefuge’ package – disappeared upstream.

Today, Guix is well covered for package using ’git-fetch’ but not for
all the others methods.  The situation is improving to have a complete
fallback using Software Heritage via Disarchive.  Not ready yet [1]. :-)

This redundancy about all sources appears to me vitally important.
Because if Berlin is totally lost for whatever reason, it is game over
for preserving Guix – well, recover from scattered with people’s store.

Other said, in term of capacity and priority, it appears to me worse if
0.01% source (or even just one) is missing than if some substitutes are
missing.  Because I can always locally burn some CPU, but I cannot
create source code. :-)

1: <>

> In addition to lakefront, I've also added a 6TB hard drive to hatysa,
> the HoneyComb LX2 machine that I host. Like lakefront, it's busy
> downloading the nars from bayfront. This will act as a backup in case
> lakefront is lost.

Cool!  Thanks.

> In general this is an important step in being more flexible where the
> nars are stored. There's still a reliance on storing pretty much all the
> nars on a single machine, but which machine has this role is more
> flexible now. I think this architecture also makes it easier to break
> the "all nars on a single machine" restriction in the future as well.

IIUC the design, if the proxy server is lost, then it is easy to replace
it.  Right?

I remember discussions about CDN [2,3,4,5,6].  I do not know if it
solves the issue but from my understanding, it will improve at least
performance delivery.  Well, it appears to me worth to give a try.

2: <>
4: <>
5: <>
6: <>

> Going forward, it would be good to have an additional full backup of the
> nars that bayfront can serve things from, to provide more
> redundancy. I'm hoping the nar-herder will also enable setting up
> geographically distributed mirrors, which will hopefully improve
> redundancy further, and maybe performance of fetching nars too.

To me, one first general question about backup coordination is to define
a window for time:

 - source: forever until the complete fallback to SWH is robust;
 - all the substitutes to run “guix time-machine --commit=<> -- help ”
   for any commit reachable by inferior: forever;
 - package substitute: rule something.

Thanks for taking care about redundancy and reliance of CI.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]