bug-guix
[Top][All Lists]
Advanced

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

bug#33370: guix publish: at least one user will have to build a given su


From: Clément Lassieur
Subject: bug#33370: guix publish: at least one user will have to build a given substitute
Date: Wed, 14 Nov 2018 00:48:40 +0100
User-agent: mu4e 1.0; emacs 26.1

Hi,

I've noticed that narinfo baking is triggered by user requests when the
'--cache' option of 'guix publish' is used.  It means that the first
user who will want it will get the 404 response and will have to build
it manually.  (See guix/scripts/publish.scm, make-request-handler.)

I was reluctant to send this email to address@hidden because it's
fairly well documented, but I don't like this behaviour...  As a matter
of fact I'm often the first user downloading substitutes on my 'guix
publish' server.

Would it be possible to trigger the baking right after the build is
done?  So that every user can be sure that they will get the substitute
once they know that Cuirass has built it.

If 'guix publish' has no way to get the notification that a build is
done, maybe Cuirass could trigger the baking?  (But that would be
hackish in my opinion.)

Cheers,
Clément

--8<---------------cut here---------------start------------->8---
‘--cache=DIRECTORY’
‘-c DIRECTORY’
     Cache archives and meta-data (‘.narinfo’ URLs) to DIRECTORY and
     only serve archives that are in cache.

     When this option is omitted, archives and meta-data are created
     on-the-fly.  This can reduce the available bandwidth, especially
     when compression is enabled, since this may become CPU-bound.
     Another drawback of the default mode is that the length of archives
     is not known in advance, so ‘guix publish’ does not add a
     ‘Content-Length’ HTTP header to its responses, which in turn
     prevents clients from knowing the amount of data being downloaded.

     Conversely, when ‘--cache’ is used, the first request for a store
     item (via a ‘.narinfo’ URL) returns 404 and triggers a background
     process to “bake” the archive—computing its ‘.narinfo’ and
     compressing the archive, if needed.  Once the archive is cached in
     DIRECTORY, subsequent requests succeed and are served directly from
     the cache, which guarantees that clients get the best possible
     bandwidth.

     The “baking” process is performed by worker threads.  By default,
     one thread per CPU core is created, but this can be customized.
     See ‘--workers’ below.

     When ‘--ttl’ is used, cached entries are automatically deleted when
     they have expired.
--8<---------------cut here---------------end--------------->8---





reply via email to

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