[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Substitute timeouts
From: |
Mathieu Othacehe |
Subject: |
Re: Substitute timeouts |
Date: |
Wed, 11 Aug 2021 13:38:13 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hey Ludo,
Thanks for taking the time to read my wall of text :D.
> Yeah, it’s a double-edged sword. If this is a problem on the main ‘guix
> publish’ server, we can lower the bypass threshold, which is currently
> 50 MiB:
>
>
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/services.scm#n450
>
> WDYT?
That would maybe help, but on the other hand, I would prefer to find a
more definitive solution :).
> First, in terms of UI, you’d have a command sitting there and doing
> nothing, which can be off-putting. Second, clients have no idea how
> long they’re going to wait; it could be that the nar is going to be
> baked within seconds, or it could take 20mn if the baking queue is
> already crowded or if the user is asking for a big store item like
> libreoffice. Third, in many cases, building locally is likely to be
> faster than waiting for substitutes to be available (the majority of
> packages build very quickly, though the few most popular leaf packages
> take a long time to build).
It would be interesting to monitor the status of the baking
workers. Could it really take 20 minutes to bake a substitute from your
experience?
Personally, I have always found this baking 404 and bypass cache a bit
misleading. When substituting libreoffice, I would much rather wait a
few minutes than trying to build it while there's an almost ready
substitute. I get that this is a personal choice and maybe it should be
an optional behaviour.
>> It will also allow the Cuirass build farm to use directly the main guix
>> publish server, simplifying the current CI setup.
>
> The only reason why Cuirass runs its own publish server is to avoid
> overloading the main one?
No, the main reason is that with the use of a publish cache, the Cuirass
workers would probably hit 404 errors while the substitutes are being
baked. Using a publish server without cache was a way to work around it.
The motivation of the 202 waiting patch was to solve both problems at
once. Maybe I should explore the narinfo dedicated thread solution as a
short term solution, while starting to think about a more long term
solution based on Fiber/Nginx.
A Cuirass dedicated solution could also be to declare a build successful
only when a nar is available and stop using a non-caching publish
server.
Thanks,
Mathieu