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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-09-29 at 17:52 +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH OSSTEST v3 3/3] Create a flight to test
> OpenStack with xen-unstable and libvirt"):
> > Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> > 
> > ---
> > Change in V3:
> > - Switch to "track" Nova tree instead of devstack.
> >     Nova is the service we care about from a Xen point of view.
> >     Also it is updated much more often than devstack.
> > - Use TREE_OPENSTACK_ as prefix for all trees variables.
> > - Change the filter, keep only *-devstack jobs.
> > - Add stuff into ./ap-push
> > - Add stuff into ./cr-daily-branch.
> > - Add 'openstack' into ./cr-for-branches.
> ...
> > +  job_create_test test-$xenarch$kern-$dom0arch-devstack \
> > +    test-devstack libvirt $xenarch $dom0arch \
> > +    tree_devstack=$TREE_OPENSTACK_DEVSTACK \
> > +    tree_requirements=$TREE_OPENSTACK_REQUIREMENTS \
> > +    tree_keystone=$TREE_OPENSTACK_KEYSTONE \
> > +    tree_glance=$TREE_OPENSTACK_GLANCE \
> > +    tree_cinder=$TREE_OPENSTACK_CINDER \
> > +    tree_nova=$TREE_OPENSTACK_NOVA \
> > +    tree_tempest=$TREE_OPENSTACK_TEMPEST \
> > +    revision_devstack=master \
> > +    revision_requirements=master \
> > +    revision_keystone=master \
> > +    revision_glance=master \
> > +    revision_cinder=master \
> > +    revision_nova=master \
> > +    revision_tempest=master \
> 
> 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).

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

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.

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?

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 you don't want to make a push gate, then you probably want to do
> away with the changes to ap-fetch and ap-push.

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

Ian.

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