From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#33378: offload: Avoid hosts with little or no free disk space Date: Mon, 24 Dec 2018 13:45:08 -0500 Message-ID: <875zviyd9s.fsf@netris.org> References: <87ftw3hio6.fsf@gnu.org> <87r2ealci0.fsf@gnu.org> <8736qoi2hf.fsf@netris.org> <87k1k0gdti.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 ([208.118.235.92]:59148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gbVFp-00040I-VF for bug-guix@gnu.org; Mon, 24 Dec 2018 13:47:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gbVFl-0003pK-W7 for bug-guix@gnu.org; Mon, 24 Dec 2018 13:47:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:51271) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gbVFl-0003pB-TC for bug-guix@gnu.org; Mon, 24 Dec 2018 13:47:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gbVFl-0003ET-O4 for bug-guix@gnu.org; Mon, 24 Dec 2018 13:47:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87k1k0gdti.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 23 Dec 2018 21:58:49 +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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 33378@debbugs.gnu.org Hi Ludovic, Ludovic Court=C3=A8s writes: > I suppose the only way to solve this correctly would be to keep the > build tree and then delete it from (guix scripts offload). WDYT? Generally, this sounds like a reasonable approach. However, one issue is that it will likely lead to build directories being left around occasionally when transient network outages occur. Those would need to be cleaned up manually, or by cron jobs on the build slaves. Also, does the daemon API provide a way to find the name of the build directory? What if there's more than one build directory with the same name and version number, differing only by the numeric suffix? Ideally, there would be a way for the build-side code to return a result code indicating that the build "aborted" rather than "failed", for this to be recognized by the daemon as a transient failure (i.e. not cached), and to propagate this information back to the client who requested the build. Do the relevant daemon APIs and offloading protocols allow for this information to be propagated to the client? Thanks, Mark