All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt
Date: Wed, 9 Nov 2016 17:11:33 +0000	[thread overview]
Message-ID: <22563.22725.68614.609274@mariner.uk.xensource.com> (raw)
In-Reply-To: <22563.19633.992915.54575@mariner.uk.xensource.com>

We just discussed this IRL, and here are our conclusions:

Ian Jackson writes ("Re: [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt"):
> Do we intend to try to gate xen-unstable on this eventually ?

Maybe eventually, but not right now.

> AFAICT you pull in new versions of all the subtrees willy-nilly.
> Isn't that likely to cause regressions ?

The openstack components other than nova are already tested by the
openstack upstream CI loop, whose output we are going to be
consuming, so regressions there will be less frequent.  They might
block our openstack-nova push gate occasionally, but it would unblock
when upstream fixed it.

Your proposed arrangements would allow the bisector to work, across
all the relevant trees.

The obvious alternative would be to set up a push gate for each
openstack subtree, which obviously not something we want to do.

There is a less-obvious alternative, to have cr-daily-branch fetch all
the openstack trees' versions together, and then push them together to
a multitude of push-gate-output branches.  This would be fairly fiddly
work in cr-daily-branch, and introduce (yet another) a new special
case there.  It's not clear that we want to do this at all.
Definitely neither of us want to do that *now*.

So overall the conclusion is that your approach is OK.

> > +: ${TREE_OPENSTACK_CINDER:=$GIT_OPENSTACK_ORG/openstack/cinder.git}
> > +: ${TREE_OPENSTACK_DEVSTACK:=$GIT_OPENSTACK_ORG/openstack-dev/devstack.git}
> > +: ${TREE_OPENSTACK_GLANCE:=$GIT_OPENSTACK_ORG/openstack/glance.git}
> > +: ${TREE_OPENSTACK_KEYSTONE:=$GIT_OPENSTACK_ORG/openstack/keystone.git}
> > +: ${TREE_OPENSTACK_NOVA:=$GIT_OPENSTACK_ORG/openstack/nova.git}
> 
> Regardless of your answer to the above, this and the part in
> make-flight could really do with some metaprogramming.

Anthony is going to go and write some shell functions.

Ian.

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

      reply	other threads:[~2016-11-09 17:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-31 17:52 [OSSTEST PATCH v6 0/3] Have OpenStack tested on top of xen's master and libvirt's master Anthony PERARD
2016-10-31 17:52 ` [OSSTEST PATCH v6 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack Anthony PERARD
2016-11-09 16:14   ` Ian Jackson
2016-10-31 17:52 ` [OSSTEST PATCH v6 2/3] ts-openstack-tempest: Run Tempest to check OpenStack Anthony PERARD
2016-11-09 16:16   ` Ian Jackson
2016-10-31 17:52 ` [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt Anthony PERARD
2016-11-09 16:20   ` Ian Jackson
2016-11-09 17:11     ` Ian Jackson [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=22563.22725.68614.609274@mariner.uk.xensource.com \
    --to=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.