Xen-Devel Archive on lore.kernel.org
 help / color / Atom feed
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
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.


> 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?


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.


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.



  reply index

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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Xen-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/xen-devel/0 xen-devel/git/0.git
	git clone --mirror https://lore.kernel.org/xen-devel/1 xen-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 xen-devel xen-devel/ https://lore.kernel.org/xen-devel \
		xen-devel@lists.xenproject.org xen-devel@lists.xen.org
	public-inbox-index xen-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git