All of lore.kernel.org
 help / color / mirror / Atom feed
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>

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.