From 8e36408db770f96840c30bbec63eb5d4d133ea5d Mon Sep 17 00:00:00 2001 From: distix ticketing system Date: Wed, 20 Feb 2019 15:59:07 +0000 Subject: imported mails --- .../Maildir/new/1550678347.M29990P29481Q1.koom | 143 +++++++++++++++++++++ 1 file changed, 143 insertions(+) create mode 100644 tickets/7503b896b90049d3a89ad5a7f4ed021d/Maildir/new/1550678347.M29990P29481Q1.koom diff --git a/tickets/7503b896b90049d3a89ad5a7f4ed021d/Maildir/new/1550678347.M29990P29481Q1.koom b/tickets/7503b896b90049d3a89ad5a7f4ed021d/Maildir/new/1550678347.M29990P29481Q1.koom new file mode 100644 index 0000000..c2b16e7 --- /dev/null +++ b/tickets/7503b896b90049d3a89ad5a7f4ed021d/Maildir/new/1550678347.M29990P29481Q1.koom @@ -0,0 +1,143 @@ +Return-Path: +X-Original-To: distix@pieni.net +Delivered-To: distix@pieni.net +Received: from yaffle.pepperfish.net (yaffle.pepperfish.net [88.99.213.221]) + by pieni.net (Postfix) with ESMTPS id 0EF9942E76 + for ; Wed, 20 Feb 2019 15:58:13 +0000 (UTC) +Received: from platypus.pepperfish.net (unknown [10.112.101.20]) + by yaffle.pepperfish.net (Postfix) with ESMTP id D0EC04111E; + Wed, 20 Feb 2019 15:58:12 +0000 (GMT) +Received: from ip6-localhost.nat ([::1] helo=platypus.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1gwUGC-0004QQ-Q6; Wed, 20 Feb 2019 15:58:12 +0000 +Received: from [10.112.101.21] (helo=mx3.pepperfish.net) + by platypus.pepperfish.net with esmtps (Exim 4.80 #2 (Debian)) + id 1gwUGB-0004Q4-Br + for ; Wed, 20 Feb 2019 15:58:11 +0000 +Received: from mail.steve.org.uk ([176.9.183.102] helo=ssh.steve.org.uk) + by mx3.pepperfish.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) + (Exim 4.89) (envelope-from ) id 1gwUG9-0000Ru-FW + for ick-discuss@ick.liw.fi; Wed, 20 Feb 2019 15:58:11 +0000 +DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; + d=steve.org.uk; s=20150726; h=References:In-Reply-To:Message-ID:Date:Subject: + From:To:Sender:Reply-To:Cc:MIME-Version:Content-Type: + Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: + Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: + List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; + bh=EOZG+lzSbTnZF4rkMB8QR/12qPYYuySwLoXgRIrMaBU=; b=WHdvz7fjyteIxpAOINHZDJX6/ + LaGsMqyUpPrdhNeaY0Hb6pUs0iW7ZZva8wzAbvtmx4mVwpEoRsl/fxA1BmPrTBoX49bWi2gQslnXh + iCyAXZJHsLwWwgBtBjfc2u6aqkjabkAADuxIz/zCcGyZ9G574sPlzffscP6cvOusRWPh0=; +Received: from steve by ssh.steve.org.uk with local (Exim 4.89) + (envelope-from ) id 1gwUG2-00006g-Uq + for ick-discuss@ick.liw.fi; Wed, 20 Feb 2019 15:58:03 +0000 +To: ick-discuss@ick.liw.fi +From: Steve Kemp +Date: Wed, 20 Feb 2019 15:54:23 +0000 +Message-ID: <1550678063.32630.0@ssh.steve.org.uk> +In-Reply-To: <20190216144009.GA5870@exolobe1.liw.fi> +References: <5e2b278847b76dd0311d5050b3455b12b4dd3077.camel@liw.fi> + <1549688875.1308.1@ssh.steve.org.uk> <20190216144009.GA5870@exolobe1.liw.fi> +X-added-header: steve.org.uk +X-Pepperfish-Transaction: 0681-bd93-c8ba-26b1 +X-Spam-Score: -2.1 +X-Spam-Score-int: -20 +X-Spam-Bar: -- +X-Scanned-By: pepperfish.net, Wed, 20 Feb 2019 15:58:11 +0000 +X-Spam-Report: Content analysis details: (-2.1 points) + pts rule name description + ---- ---------------------- -------------------------------------------------- + -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% + [score: 0.0000] + -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from + envelope-from domain + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily + valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-ACL-Warn: message may be spam +X-Scan-Signature: 78c34a7242bc3b0cdb4980a2406d4978 +Subject: Re: Plan for using Muck for the Ick controller +X-BeenThere: ick-discuss@ick.liw.fi +X-Mailman-Version: 2.1.5 +Precedence: list +List-Id: discussions about the ick CI system +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +Sender: ick-discuss-bounces@ick.liw.fi +Errors-To: ick-discuss-bounces@ick.liw.fi + +> (Sorry about taking so long to answer: I was travelling for work.) + + No worries. + +> You're right, this scales badly to long build logs, because of the +> large number of HTTP requests required. (The size of the logs is so +> much less of an issue I'm going to ignore that for now.) + +> For now, I think I'm OK with that, if it's fast enough for +> not-very-long build logs. From my personal Ick instance, the longest +> log files are about 14000 lines. + + I suspect this depends upon what you're building; for complicated + reasons at work I'm creating images which build nginx, php, curl, + and similar things from source. The build output from such jobs + is pretty volumous. At home I tend to build linux-kernels which + also have a good few thousand lines of output. + +> This is not excellent. Is it tolerable? Not very tolerable for +> interactive use. I'm not much worried, for now, about the time it +> takes to create the log file snippets, that's going to be drowned by +> the actual build. The time to get the list of snippets is fast enough, +> I think, even in the current prototype written in Python without +> indexes. + + That's probably fair. + +> The full log assembly time is bad. As you say, it's because there's a +> lot of HTTP requests. It might be tolerable for a short while, while +> we improve things, just to get the Ick controller to use Muck instead +> of having local state, but let's discuss how we can improve it. + + That's probably a good approach. When it comes to builds in my + current system I have to say that I tend to scroll straight to + the bottom to look for an "All OK", or "ERROR/FAIL" message. + + The stuff in the middle I don't care about so much very often. + I'd not suggest that having a ring-buffer was a good idea, but if + it were possible to keep track of the last update that might be + a compromise worth making. + +> I don't like the idea of keeping the log file locally, either on the +> worker-manager or the controller, as it means that one can't do the +> equivalent of "tail -f" while the build is running. Updating the +> controller's view of the log while the build is running, without +> lagging much from actual output, is a thing I'd really like to keep. + + Sure. + + I suspect when everything is done the build-log belongs with the + output artifacts, in the object-store. That might be personal + bias at play of course. + +> * new step: if there are more than M short snippet objects for a +> build, the controller would construct a combined snippet object, and +> delete the short snippet objects +> * new step: at the end of the build, the controller would comine all +> short snippet objects + + That seems like a good idea. + +Steve +-- +https://www.steve.org.uk/ + +_______________________________________________ +ick-discuss mailing list +ick-discuss@ick.liw.fi +https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi -- cgit v1.2.1