From: Ian Jackson <iwj@xenproject.org>
To: Edwin Torok <edvin.torok@citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org,
"Christian Lindig" <christian.lindig@citrix.com>,
"Jürgen Groß" <jgross@suse.com>, "Wei Liu" <wl@xen.org>
Subject: Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored [and 2 more messages]
Date: Fri, 22 Jan 2021 17:37:12 +0000 [thread overview]
Message-ID: <24587.3400.673049.196349@mariner.uk.xensource.com> (raw)
In-Reply-To: <a436baeb-888e-a213-2a68-6817309a6b2a@citrix.com>, <81f92e66-3a43-dea8-f633-2fcf725c10dc@citrix.com>, <8b231075e5ed13412f98881c3b3454d9abf9e871.camel@citrix.com>
Andrew Cooper writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored"):
> Right, but nothing will actually fail the build.
Indeed.
> So the way this error will manifest is the first non-trivial `xl $FOO`
> executed in dom0 hanging until the job timeout.
I doubt it would produce a timeout BICBW.
> Or does OSSTest have an explicit "is xenstored running" check after
> boot, before any further testing occurs?
No.
If this turns out to ever happen we can improve the pre-checking. In
general I let the chips fall where they may, for test failures, and
improve the checking/logging later. Otherwise adding new tests
becomes very time-consuming (and there is also the risk that added
checks do not align with actual behvaiour).
Now that it's builing, I think it's fairly unlikely that we will
accidentally stop building one of the xenstoreds.
> There is no such thing as an ocaml stub-xenstored yet, but I have asked
> the Mirage folk if they'd like to remedy this.
Cool.
Andrew Cooper writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored"):
> An extra thought. What exactly feeds into the decision?
Precisely, the job name.
> If it includes the flight number, then the retest logic is going to get
> very confused on xenstored bugs when the implementation change between
> the two runs.
Indeed. But it doesn't :-).
> Also, what is the bisector going across this changeset?
The bisector always runs with the latest osstest. So if this new C
xenstore testing discovers that it's broken, the bisector won't be
much help. (It will fail to repro the basis pass; so in any case we
won't get false reports from it.)
On the other hand, if C xenstored still works and some future point we
break it, the bisection will DTRT.
Edwin Torok writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored"):
> In the patch series that I've recently posted to xen-devel there is
> also a 'make check' target in tools/ocaml/xenstored.
Cool.
Thanks,
Ian.
next prev parent reply other threads:[~2021-01-22 17:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-22 15:55 [OSSTEST PATCH 1/7] target_editfile_kvp_replace: Support changing multiple keys Ian Jackson
2021-01-22 15:55 ` [OSSTEST PATCH 2/7] target_editfile_kvp_replace: Add a bit of logging Ian Jackson
2021-01-22 15:55 ` [OSSTEST PATCH 3/7] ts-xen-install: Rename $commons_config_file Ian Jackson
2021-01-22 15:56 ` [OSSTEST PATCH 4/7] ts-xen-install: Break out @commons_config Ian Jackson
2021-01-22 15:56 ` [OSSTEST PATCH 5/7] ts-xen-install: Honour xenstored target var Ian Jackson
2021-01-22 15:56 ` [OSSTEST PATCH 6/7] mfi-common: Provide stripy_rand Ian Jackson
2021-01-22 15:56 ` [OSSTEST PATCH 7/7] make-flight: Stripy xenstored Ian Jackson
2021-01-22 16:07 ` Andrew Cooper
2021-01-22 16:22 ` Ian Jackson
2021-01-22 16:24 ` Jürgen Groß
2021-01-22 16:26 ` Ian Jackson
2021-01-22 16:29 ` Jürgen Groß
2021-01-22 16:29 ` Andrew Cooper
2021-01-22 17:37 ` Ian Jackson [this message]
2021-01-22 17:52 ` [OSSTEST PATCH 7/7] make-flight: Stripy xenstored [and 2 more messages] Andrew Cooper
2021-01-28 14:26 ` Ian Jackson
2021-01-22 16:11 ` [OSSTEST PATCH 7/7] make-flight: Stripy xenstored Christian Lindig
2021-01-22 16:36 ` Andrew Cooper
2021-01-22 16:40 ` Edwin Torok
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=24587.3400.673049.196349@mariner.uk.xensource.com \
--to=iwj@xenproject.org \
--cc=andrew.cooper3@citrix.com \
--cc=christian.lindig@citrix.com \
--cc=edvin.torok@citrix.com \
--cc=jgross@suse.com \
--cc=wl@xen.org \
--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).