All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>
Cc: xen-devel@lists.xenproject.org, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [OSSTEST PATCH 2/2] make-flight: create the vNUMA HVM test job
Date: Tue, 6 Oct 2015 10:18:40 +0100	[thread overview]
Message-ID: <1444123120.5302.66.camel@citrix.com> (raw)
In-Reply-To: <20151006090503.GO29124@zion.uk.xensource.com>

On Tue, 2015-10-06 at 10:05 +0100, Wei Liu wrote:
> On Tue, Oct 06, 2015 at 10:33:24AM +0200, Dario Faggioli wrote:
> > On Tue, 2015-10-06 at 09:23 +0100, Ian Campbell wrote:
> > > On Mon, 2015-10-05 at 17:41 +0100, Wei Liu wrote:
> > 
> > > > We don't need to make ts-migrate-support-check fail. It is fine for
> > > > the
> > > > actual migration test to fail at the beginning as it won't block
> > > > the
> > > > push gate. It's conceivable that vNUMA guest will be able to
> > > > migrate in
> > > > the future. When that comes true, the actual migration test will
> > > > pass.
> > > 
> > > I think the point was that if the migration tests fails then all
> > > subsequent
> > > test steps won't get run at all (apart from leak check & log
> > > collection
> > > etc).
> > > 
> > By "test steps" you mean things like other ts-* within the same (vNUMA)
> > job? Or something different, e.g., other tests on the same host, etc?
> > 
> > If the former (which I think is the case), that's not really a big
> > deal, as there are no other steps. :-)
> > 
> > > Whereas if ts-migrate-support-check fails then the migrations will be
> > > skipped and those other tests will be run.
> > > 
> > The above being said, I wasn't sure how to procede myself. I went for
> > this approach, following Wei's advice (on IRC), and I still think it's
> > a valid one, in line with how new tests have been handled since now...
> > unless there are downsides that I'm not seeing. For example, would the
> > failure be sticky, i.e., this test will be kept on the same host,
> > preventing other tests to run there?
> > 
> 
> We had a (wrong) assumption that even if the migration test fails the
> rest test steps will still run. Ian said this is not true. All
> subsequent test steps except for log collection will be skipped, e.g.
> guest-start.repeat / guest-stop.repeat etc.

Right, this arises from this bit of sg-run-job
    per-host-ts .       =(*)             {ts-leak-check basis}

    if {$ok} { catching-otherwise fail      run-job/$jobinfo(recipe)      }
    per-host-ts .       =                {ts-leak-check check}

Where the run-job/* essentially throws an exception on fail, which is then
caught by catching-otherwise and turned into the job result before
continuing.

Ian.

  reply	other threads:[~2015-10-06  9:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01 23:17 [OSSTEST PATCH 0/2] Testcase for HVM vNUMA Dario Faggioli
2015-10-01 23:17 ` [OSSTEST PATCH 1/2] TestSupport.pm: allow creating vNUMA enabled HVM guest configs Dario Faggioli
2015-10-02 11:32   ` Wei Liu
2015-10-02 12:02     ` Dario Faggioli
2015-10-02 12:18       ` Wei Liu
2015-10-02 12:30         ` Dario Faggioli
2015-10-02 12:21       ` Wei Liu
2015-10-02 12:32         ` Dario Faggioli
2015-10-01 23:17 ` [OSSTEST PATCH 2/2] make-flight: create the vNUMA HVM test job Dario Faggioli
2015-10-05 16:34   ` Ian Jackson
2015-10-05 16:41     ` Wei Liu
2015-10-06  8:23       ` Ian Campbell
2015-10-06  8:33         ` Dario Faggioli
2015-10-06  9:03           ` Ian Campbell
2015-10-06  9:13             ` Dario Faggioli
2015-10-06  9:05           ` Wei Liu
2015-10-06  9:18             ` Ian Campbell [this message]
2015-10-09 14:42   ` Ian Campbell
2015-10-02  9:33 ` [OSSTEST PATCH 0/2] Testcase for HVM vNUMA Dario Faggioli
2015-10-02 10:15 ` Dario Faggioli
2015-10-02 11:40   ` Wei Liu

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=1444123120.5302.66.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=wei.liu2@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.