From patchwork Thu Dec 17 17:06:00 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ian Jackson X-Patchwork-Id: 7875171 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 87D7FBEEE5 for ; Thu, 17 Dec 2015 17:09:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 97BAB2042C for ; Thu, 17 Dec 2015 17:09:25 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8FC9820254 for ; Thu, 17 Dec 2015 17:09:24 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a9c0W-0005v7-C1; Thu, 17 Dec 2015 17:06:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a9c0T-0005tu-6x for xen-devel@lists.xenproject.org; Thu, 17 Dec 2015 17:06:21 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id C7/1F-00475-C8BE2765; Thu, 17 Dec 2015 17:06:20 +0000 X-Env-Sender: prvs=7867bb76c=Ian.Jackson@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1450371977!11725696!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18044 invoked from network); 17 Dec 2015 17:06:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 17 Dec 2015 17:06:19 -0000 X-IronPort-AV: E=Sophos;i="5.20,442,1444694400"; d="scan'208";a="326045250" From: Ian Jackson To: Date: Thu, 17 Dec 2015 17:06:00 +0000 Message-ID: <1450371968-27997-1-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.10.4 MIME-Version: 1.0 X-DLP: MIA1 Cc: Ian Jackson , Ian Campbell Subject: [Xen-devel] [OSSTEST PATCH 1/9] README.dev: Document the blessings X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Signed-off-by: Ian Jackson --- README.dev | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) diff --git a/README.dev b/README.dev index 65ec111..879af60 100644 --- a/README.dev +++ b/README.dev @@ -232,3 +232,104 @@ probably are after a reboot) by looking for processes relating to the lists flight,job combinations and then: $ ./mg-hosts previoustasks --clear + + +Flight blessings and the blessed-* host flags +============================================= + +Both flights and hosts have a `blessing'. + +Blessings are used: + + * To avoid accidentally tools operating on flights which are in the + wrong phase of their existence. + + * To control which automatic archaeologists will look at which + flights. (Archeaology tools take arguments to control which + blessings they will consider.) + + * To control which hosts are considered suitable for use with which + flight. (Flights with blessing `foo' use only hosts which have + flag `blessed-foo'.) + +Each flight has a `blessing' and an `intended blessing'. The +`intended blessing' is what the flight is going to be blessed as when +its execution has completed. The intended blessing controls host +allocation. + +(Normally the `intended blessing' is the same as the bless argument to +sg-execute-flight aka the -B argument to mg-execute-flight.) + +These are the principal (intended) blessings: + + * `real': Flights which are fully production runs. They use only + clean working trees with no `funny' environment variables, and + versions of osstest intended for production. The data from such + flights is used, where applicable, to control production push gate + decisions, etc. + + `blessed-real' hosts are fully production-ready. + + * `play': Playground. Flights may use weird software, dirty working + trees, strange environment variables, and so on. It does not make + sense to point archaeology tools at such flights. + + `blessed-play' hosts may be partially or completely nonfunctional, + or strange in some way. For this reason `play' flights should not + normally use the automatic host allocator. + + * `adhoc': Special-purpose flights. They should be run with software + nearly as clean as `real': the version of the software used may not + be a branch intended for-production, but any enhancements or + modifications should not leave false or misleading information in + the history database. + + `blessed-adhoc' hosts are just as good as `blessed-real' ones. + + The `adhoc' blessing exists mostly to protect the main production + workflow from unintentional violations (for example, unexpectedly + buggy historical flight data). + + * `commission-': Flights used for testing that a + particular subset of the hosts are working properly. The hosts to + be tested should be blessed `commission-whatever' during + commissioning, and that blessing removed and replaced with `real' + when the hosts are ready. + + * `real-bisect' and `adhoc-bisect': These are found only as the + blessing of finished flights. (This is achieved by passing *-adhoc + to sg-execute-flight.) This allows the archaeologist tools to + distinguish full flights from bisection steps. + + The corresponding intended blessing (as found in the `intended' + column of the flights table) is `real'. So the hosts used by the + automatic host allocator are those flagged `blessed-real' or + `blessed-adhoc' - there are no separate blessed-*-bisect hostflags. + +There are also blessings for unfinished flights: + + * `constructing': The flight metadata (jobs, runvars, etc.) is still + being populated. The tools for flight construction (and flight + construct editing) generally insist that they operate only on + flights in this state. + + * `running': At least one of the jobs in this flight has started. + Flight execution software will generally (perhaps via standard + library calls) mark a flight `running' if they find it + `constructing', and refuse to operate on other flights. + + * `broken': Something went catastrophically wrong. + +Note that osstest is generally `crash-only software': nothing will +`clean up' a crashed flight and set its blessing to `broken'. Flights +which were in progress once upon a time but never completed, because +they crashed, are simply left with whatever blessing they had at the +time. + +There is a special exception to the tools' flight status checks: any +flight whose blessing contains `play' can be operated on out of order. + +Flights blessings can be manually changed with cs-flight-bless. Eg + ./cs-flight-bless FLIGHT broken-real real +updates FLIGHT to be marked `broken' rather than `real'. This can be +useful if a flight's data is misleading to the archaeologists.