From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#26201: hydra.gnu.org uses =?UTF-8?Q?=E2=80=98guix_?= =?UTF-8?Q?publish=E2=80=99?= for nars and narinfos Date: Tue, 18 Apr 2017 23:27:44 +0200 Message-ID: <87o9vts8xb.fsf@gnu.org> References: <20170320184449.5ac06051@khaalida> <144e9ba8-af93-fb18-d2b9-f198ae7c11e9@tobias.gr> <20170320195247.05f72fc9@khaalida> <8e7e07d1-563f-666f-2c32-2a772757c86f@tobias.gr> <8760j2wpfy.fsf@gnu.org> <9889a4b5-c300-cd03-1095-1115428067fb@tobias.gr> <87r31pyms2.fsf_-_@gnu.org> <87inmzrgbf.fsf@netris.org> <25b2472a-c705-53fe-f94f-04de9a2d484e@tobias.gr> <87y3vvozy5.fsf@netris.org> <87d1d710xc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0agN-0000gu-Eb for bug-guix@gnu.org; Tue, 18 Apr 2017 17:29:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0agI-00014k-AY for bug-guix@gnu.org; Tue, 18 Apr 2017 17:29:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:57076) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d0agI-00014e-7W for bug-guix@gnu.org; Tue, 18 Apr 2017 17:29:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d0agH-0003Gr-VD for bug-guix@gnu.org; Tue, 18 Apr 2017 17:29:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87d1d710xc.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 24 Mar 2017 10:25:35 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 26201@debbugs.gnu.org, guix-sysadmin@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) skribis: > 2. Produce a narinfo and corresponding nar the first time they are > requested. So, the first time we receive =E2=80=9CGET foo.narinfo= =E2=80=9D, return > 404 and spawn a thread to compute foo.narinfo and foo.nar. Return > 200 only when both are ready. > > The precomputed nar{,info}s would be kept in a cache and we could > make sure a narinfo and its nar have the same lifetime, which > addresses one of the problems we have. > > pros: better HTTP latency and bandwidth > pros: allows us to add a Content-Length for nars > pros: helps keep narinfo/nar lifetime in sync > cons: doesn=E2=80=99t reduce load on hydra.gnu.org > cons: exposes inconsistency between the store contents and the HTTP > response (you may get 404 even if the thing is actually in > store), but maybe that=E2=80=99s not a problem Implemented in commit 00753f7038234a0f5a79be3ec9ab949840a18743. I=E2=80=99ll set up a test instance shortly. Ludo=E2=80=99.