Hi Chris, Thanks for the update. And for the all work. :-)
On Wed, 15 Dec 2021 at 16:48, Christopher Baines <m...@cbaines.net> 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 <https://git.savannah.gnu.org/cgit/guix.git/tree/etc/source-manifest.scm> ? 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: <https://ngyro.com/pog-reports/2021-12-06/> > 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: <https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00312.html> 3: <https://yhetil.org/guix/KBlEbLsxWu2Kmv5RvS2dHXDleGAyyz9WEA0T6wQ1QArc0mjkol-1W5Vv66D9oauvQ5l6WYTaJ86Ckxjc8YS_2pn2NN1M_L8RJUsIBmmFeqE=@protonmail.ch/> 4: <https://yhetil.org/guix/87tvju6145....@gnu.org/> 5: <https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00192.html> 6: <https://yhetil.org/guix/87d0my1380....@gmail.com/> > 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. Cheers, simon
