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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Thu, Oct 08, 2015 at 05:42:56PM +0100, Ian Jackson wrote:
> 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.

Yes, that is what I had in mind, testing OpenStack with tips of xen and
libvirt.

I'll remove all those revision_* runvars.

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

-- 
Anthony PERARD

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