Re: [Xen-devel] [PATCH OSSTEST v3 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [PATCH OSSTEST v3 3/3] Create a flight to test 
OpenStack with xen-unstable and libvirt"):
> On Tue, 2015-09-29 at 17:52 +0100, Ian Jackson wrote:
> > All these revision_FOO=master are rather odd.
> 
> I think the revision_nova one was supposed to be $REVISION_OPENSTACK_NOVA?
> 
> AIUI Nova is the component which we care about (it's the "compute" bit of
> openstack) and changes frequently compared with devstack (the overall
> driver).

And the others we don't care about ?  Are they likely to break things
anyway, is my point ?  Do they have uniform intercompatibility ?

> >   You seem to be creating
> > a push gate which maintains a tested revision of `openstack-nova'.  Is
> > that what you want ?  If so, then it's not really clear to me that
> > what you want to do is to simply pick up new master revisions of these
> > other git trees.  It might be better to obtain a bunch of revision
> > ids, test them all together, and push them together ?
> 
> i.e. to have multiple output gates, one for each of those trees, each
> pushed from a single flight?

Yes.

> I'm assuming you aren't talking about having N openstack flights, one for
> each tree.
> 
> >   (This is not
> > something that osstest can do right now but it doesn't seem
> > difficult.)
> 
> It seems like quite a lot of faff in cr-daily-branch (what does $tree mean,
> which $NEW_REVISION and $OLD_REVISION do we look at), ap-push now needs to
> operate on a list or something (arguments?).
> 
> Getting this stuff right (i.e. testing) is quite hard even with access to a
> production instance.

I can think of ways of doing it.  I wasn't expecting Anthony to
produce them :-).  Right now I'm trying to understand the situation,
and if I think we want to push multiple trees at once I'll write the
code.

> The series today records the actual built versions, so we still get
> bisections, what would having multiple output gates buy us in practice over
> that?

I guess the main advantage is that other osstest `branches' could have
a stable set of openstack things, and that the reporting of `what
changed' would be accurate.

> Maybe the explicit =master stuff above should be removed, or replaced with
> $REVISION_OPENSTACK_FOO which apart from NOVA are _not_ set by cr-daily
> -branch (resulting in cloning master)?

If we do want to just ignore this issue of the other trees, I do
indeed see no particular reason to explicitly set all the runvars to
master.

> I think we want a push gate just for the regression tracking, but not
> really for its own sake.

In that case we I think yes don't really need to push multiple branches.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel