From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 1/9] README.dev: Document the blessings
Date: Thu, 17 Dec 2015 17:18:52 +0000 [thread overview]
Message-ID: <1450372732.4053.136.camel@citrix.com> (raw)
In-Reply-To: <1450371968-27997-1-git-send-email-ian.jackson@eu.citrix.com>
On Thu, 2015-12-17 at 17:06 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
> 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
Archaeology
> + 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.
I think this could also usefully mention that `blessing' is the current
blessing, which may go through several phases during the life of the
flight, hopefully culminating in being set to `intended blessing' if the
flight is successful and that the archaeology tools only look at `blessing'
and never `intended blessing'
> +(Normally the `intended blessing' is the same as the bless argument to
> +sg-execute-flight aka the -B argument to mg-execute-flight.)
How does this interact with the intended blessing passed to cs-flight-
create?
> + * `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.
I don't follow the reference to *-adhoc here, since it matches neither
`real-bisect' nor `adhoc-bisect'.
> +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
The example says `broken-real' but the text says `broken' (if the text
didn't quote the `broken' it probably wouldn't matter.
Maybe mention the need to pass the current blessing as a safety catch,
since it is part of the example command?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-12-17 17:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 17:06 [OSSTEST PATCH 1/9] README.dev: Document the blessings Ian Jackson
2015-12-17 17:06 ` [OSSTEST PATCH 2/9] mg-schema-test-database: Provide some timeouts which are better for testing Ian Jackson
2015-12-17 17:19 ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 3/9] mg-schema-test-database: Wipe previous local plan data Ian Jackson
2015-12-17 17:22 ` Ian Campbell
2015-12-17 17:37 ` Ian Jackson
2015-12-17 17:42 ` Ian Campbell
2015-12-17 17:50 ` Ian Jackson
2015-12-17 18:11 ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 4/9] mg-schema-test-database: Borrow shares properly Ian Jackson
2015-12-17 17:26 ` Ian Campbell
2015-12-17 17:43 ` Ian Jackson
2015-12-17 18:08 ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 5/9] ms-planner: Improve an error message Ian Jackson
2015-12-17 17:26 ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 6/9] db_retry: Suppress an "exiting via last" warning Ian Jackson
2015-12-17 17:31 ` Ian Campbell
2015-12-17 17:48 ` Ian Jackson
2015-12-17 18:10 ` Ian Campbell
2015-12-17 18:38 ` Ian Jackson
2015-12-18 11:14 ` Ian Campbell
2015-12-18 14:39 ` Ian Jackson
2015-12-17 17:06 ` [OSSTEST PATCH 7/9] Executive DB retry: Avoid an undefined warning Ian Jackson
2015-12-17 17:31 ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 8/9] mg-allocate: Better error handling when no candidates Ian Jackson
2015-12-17 17:33 ` Ian Campbell
2015-12-17 17:06 ` [OSSTEST PATCH 9/9] mg-allocate: In planner mode, pre-check the arguments Ian Jackson
2015-12-17 17:33 ` Ian Campbell
2015-12-17 17:18 ` Ian Campbell [this message]
2015-12-17 17:59 ` [OSSTEST PATCH 1/9] README.dev: Document the blessings Ian Jackson
2015-12-17 18:12 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1450372732.4053.136.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).