From: Ian Campbell <ian.campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [PATCH OSSTEST 0/4] Have OpenStack tested on top of xen's master and libvirt's master.
Date: Mon, 20 Jul 2015 16:35:30 +0100 [thread overview]
Message-ID: <1437406530.17368.53.camel@citrix.com> (raw)
In-Reply-To: <20150720150720.GD1379@perard.uk.xensource.com>
On Mon, 2015-07-20 at 16:07 +0100, Anthony PERARD wrote:
> > > I have not done it, but we could have some smoke test before
> > > Tempest where osstest tryied to start a guest.
> >
> > A test can have a dependency on a build job, but I'm not sure about
> > another test, but that would seem generally useful and would allow your
> > new test to depend on test-ARCH-ARCH-libvirt.
>
> I was thinking of an extra steps within the test which would just start a
> guest via OpenStack/Nova before running the full test suite from Tempest.
ISWYM.
That might be nice, if it were very little osstest-development effort to
make it happen, but I think it isn't going to be a small effort and
running tempest and seeing what happens seems like it would be good
enough anyway.
> > > Then later, there will be the question of which tree to track, devstack?
> > > nova? Or don't track any and just test with the master branch from time to
> > > time.
> >
> > This is a complicated one, especially for things which don't fit into
> > the "one tree one branch" model of things...
> >
> > In terms of gating (which matters to us for regression tracking even if
> > we don't care about the output of the gate) is it the case that if you
> > clone $rootthing (whatever that is) and select a given revision of that
> > you will always get the same thing?
>
> > Or is it like raisin where you clone $rootthing and select a revision of
> > that and it will clone the latest version of everything at that time?
> >
> > I'm expecting the second one?
>
> Yes, I think your description of raisin would match the description of
> devstack, the $rootthing.
> So, devstack will clone master of every other tree by default. But we
> can select a specific revision for everything that is going to be cloned.
>
> Also, if one clone a stable/* branch of devstack, then we'll get the same
> stable branch of every other trees.
But in the presence of stable backports we may not get the exact same
set of commits from one day to the next, despite cloning the exact same
devstack revision, I think?
> > I think the important thing is we would want to be testing stuff which
> > has already gone through openstack testing?
>
> Yes. Everything in OpenStack trees have been tested and have gone through
> the gate anyway.
>
> > Maybe we want to track particular OStack releases?
>
> I think tracking master at first would be fine.
Right.
prev parent reply other threads:[~2015-07-20 15:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 11:18 [PATCH OSSTEST 0/4] Have OpenStack tested on top of xen's master and libvirt's master Anthony PERARD
2015-07-16 11:18 ` [PATCH OSSTEST 1/4] ts-kernel-build: Enable CONFIG_NETFILTER_XT_TARGET_CHECKSUM Anthony PERARD
2015-07-17 15:48 ` Ian Campbell
2015-07-16 11:18 ` [PATCH OSSTEST 2/4] Toolstack: Add OpenStack as a toolstack Anthony PERARD
2015-07-17 15:58 ` Ian Campbell
2015-07-17 16:32 ` Anthony PERARD
2015-07-17 16:45 ` Ian Campbell
2015-07-16 11:18 ` [PATCH OSSTEST 3/4] ts-devstack: Deploy OpenStack then test it with Tempest Anthony PERARD
2015-07-17 16:04 ` Ian Campbell
2015-07-20 14:12 ` Anthony PERARD
2015-07-20 14:31 ` Ian Campbell
2015-07-17 16:10 ` Ian Campbell
2015-07-20 14:16 ` Anthony PERARD
2015-07-16 11:18 ` [PATCH OSSTEST 4/4] Create a flight to test OpenStack with xen-unstable and libvirt Anthony PERARD
2015-07-17 16:08 ` Ian Campbell
2015-07-17 15:51 ` [PATCH OSSTEST 0/4] Have OpenStack tested on top of xen's master and libvirt's master Ian Campbell
2015-07-17 16:22 ` Ian Campbell
2015-07-20 15:07 ` Anthony PERARD
2015-07-20 15:27 ` Ian Jackson
2015-07-20 15:35 ` 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=1437406530.17368.53.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=anthony.perard@citrix.com \
--cc=xen-devel@lists.xen.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.