From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 1/9] README.dev: Document the blessings
Date: Thu, 17 Dec 2015 18:12:19 +0000 [thread overview]
Message-ID: <1450375939.1617.88.camel@citrix.com> (raw)
In-Reply-To: <22130.63508.987712.357028@mariner.uk.xensource.com>
On Thu, 2015-12-17 at 17:59 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 1/9] README.dev: Document
> the blessings"):
> > On Thu, 2015-12-17 at 17:06 +0000, Ian Jackson wrote:
> > > +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'
>
> Yes.
>
> > > +(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?
>
> So actually there a flight has three blessings.
>
> > > + * `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'.
>
> `Passing *-adhoc' should read `Passing *-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.
>
> I have clarified this.
>
> > Maybe mention the need to pass the current blessing as a safety
> catch,
> > since it is part of the example command?
>
> Yes.
>
> squash! patch and complete v2, below.
>
> Ian.
>
> From 73903500006c0451cc81697872096fe2d6fe02ab Mon Sep 17 00:00:00
> 2001
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Date: Thu, 17 Dec 2015 17:58:41 +0000
> Subject: [OSSTEST PATCH] squash! README.dev: Document the blessings
>
> v2: Improvements from review
Acked-by: Ian Campbell <ian.campbell@citrix.com>
prev parent reply other threads:[~2015-12-17 18:13 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 ` [OSSTEST PATCH 1/9] README.dev: Document the blessings Ian Campbell
2015-12-17 17:59 ` Ian Jackson
2015-12-17 18:12 ` Ian Campbell [this message]
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=1450375939.1617.88.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).