From: Ian Campbell <ian.campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
ian.jackson@eu.citrix.com,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [xen-unstable test] 57852: regressions - FAIL
Date: Mon, 8 Jun 2015 09:53:10 +0100 [thread overview]
Message-ID: <1433753590.7108.392.camel@citrix.com> (raw)
In-Reply-To: <557569610200007800081D4C@mail.emea.novell.com>
On Mon, 2015-06-08 at 09:07 +0100, Jan Beulich wrote:
> >>> On 05.06.15 at 12:48, <ian.campbell@citrix.com> wrote:
> > On Fri, 2015-06-05 at 10:18 +0100, Jan Beulich wrote:
> >> >>> On 05.06.15 at 11:07, <ian.campbell@citrix.com> wrote:
> >> > WRT the move to the colo, flights in 5xxxx are in the new one, while
> >> > 3xxxx are in the old one,
> >> > http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64
> >> > -xl-qemuu-win7-amd64.xen-unstable.html
> >> > shows that things seemed ok for 8 consecutive runs after the move
> >> > (ignoring blockages).
> >>
> >> And when it went live, all systems being in use now got immediately
> >> deployed?
> >
> > All the flights in the new colo seem to have been on fiano[01].
>
> So are there just two hosts to run all x86 tests on? I thought one
> of the purposes of the switch was to have a wider pool of test
> systems...
There are about a dozen, but when a test is failing osstest will have a
preference for the host on which it failed last time (i.e. failures
become sticky to the host), in order to catch host specific failures I
think.
I think it was just coincidence that the first group of runs which
passed were on fiano0, although perhaps the pool was smaller then since
the colo was in the process of being commissioned.
The stickiness does make it a bit harder to know if a failure is host
specific though, since you often don't get results for other systems.
> > But having looked at the page again the early success was all on fiano0
> > while the later failures were all on fiano1.
>
> But that's for the unstable install failures only as it looks. At the
> example of flight 57955 (testing 4.2) a local migration failure was
> observed on fiano0. Which would seem to support your earlier
> assumption that the install and migration issues are likely unrelated
> (yet their coincidence still strikes me as odd).
http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemuu-win7-amd64.html has the cross branch history for this test case. With one exception (on chardonay0, in a linux-next test) all the fails were on fiano[01] and they were all on branches which would use xen-unstable as the Xen version (xen-unstable itself and linux-* + qemu-mainline which both use the current xen.git#master as their Xen).
I've got some adhoc results over the weekend, all can be found at
http://logs.test-lab.xenproject.org/osstest/logs/<NNNNN>/test-amd64-amd64-xl-qemuu-win7-amd64/info.html for flight <NNNNN>. All of them are using the binaries from 57852.
I messed up my first command line and ran them all on fiano0 by mistake,
so there are more results than I was planning for.
Flight Host Failed at Install step duration
57940 fiano0 ts-guest-stop 1483
57945 fiano0 ts-guest-stop 1640
57953 fiano0 ts-guest-stop 1473
57958 fiano0 ts-guest-stop 1472
57962 fiano0 windows-install 7512
57973 fiano0 windows-install 7693
57080 fiano0 ts-guest-stop 1534
57986 fiano0 windows-install 7203
57933 fiano0 ts-guest-stop 1529
57997 fiano0 ts-guest-stop 1494
58004 fiano0 ts-guest-stop 1492
58011 fiano1 ts-guest-stop 1408
58012 fiano1 ts-guest-stop 1529
58017 fiano1 ts-guest-stop 1466
58023 fiano1 ts-guest-stop 1624
58028 fiano1 windows-install 7208
58038 fiano1 ts-guest-stop 1479
58043 fiano1 ts-guest-stop 1493
58053 fiano0 windows-install 7439
58062 fiano0 windows-install 1916
58063 fiano0 windows-install 1477
58067 fiano1 ts-guest-stop 1453
58071 fiano1 ts-guest-stop 1550
58077 fiano1 windows-install 7156
That's 6/14 (43%) failure rate on fiano0 and 2/10 (20%) on fiano1. Which
differs form the apparent xen-unstable failure rate. But I wouldn't take
this as evidence that the two systems differ significantly, despite how
the unstable results looked at first glance.
On successful install the test step takes 1450-1650s, with one outlier
at 1916. The failures take 7000-7500s (test case timeout is 7000, so
with slop that fits). So on success it takes <30mins and on fail it has
been given nearly 2hours.
Ian.
next prev parent reply other threads:[~2015-06-08 8:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 12:01 [xen-unstable test] 57852: regressions - FAIL osstest service user
2015-06-05 8:45 ` Ian Campbell
2015-06-05 9:00 ` Jan Beulich
2015-06-05 9:07 ` Ian Campbell
2015-06-05 9:18 ` Jan Beulich
2015-06-05 10:48 ` Ian Campbell
2015-06-05 16:46 ` Ian Campbell
2015-06-08 8:07 ` Jan Beulich
2015-06-08 8:53 ` Ian Campbell [this message]
2015-06-08 9:15 ` Jan Beulich
2015-06-08 9:27 ` Ian Campbell
2015-06-08 10:17 ` Jan Beulich
2015-06-08 14:43 ` Ian Jackson
2015-06-08 12:16 ` Ian Campbell
2015-06-08 12:19 ` Andrew Cooper
2015-06-08 12:24 ` Jan Beulich
2015-06-09 8:26 ` Ian Campbell
2015-06-09 9:29 ` Jan Beulich
2015-06-10 8:50 ` Ian Campbell
2015-06-10 9:36 ` Jan Beulich
2015-06-10 11:01 ` Ian Campbell
2015-06-10 11:48 ` Jan Beulich
2015-06-10 12:56 ` Ian Campbell
2015-06-10 13:23 ` Jan Beulich
2015-06-10 13:45 ` Jan Beulich
2015-06-10 14:08 ` Ian Campbell
2015-06-11 7:02 ` Jan Beulich
2015-06-11 8:45 ` Ian Campbell
2015-06-15 8:57 ` Ian Campbell
2015-06-15 9:03 ` Jan Beulich
2015-06-10 14:34 ` Ian Campbell
2015-06-10 15:59 ` Jan Beulich
2015-06-10 16:18 ` Don Slutz
2015-06-10 18:00 ` Ian Campbell
2015-06-08 13:50 ` Konrad Rzeszutek Wilk
2015-06-08 14:02 ` Ian Campbell
2015-06-08 14:47 ` Ian Jackson
2015-06-08 15:21 ` Konrad Rzeszutek Wilk
2015-06-08 15:29 ` Ian Campbell
2015-06-08 10:10 ` 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=1433753590.7108.392.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=JBeulich@suse.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.