[openstack-dev] Updating libvirt in gate jobs
joe.gordon0 at gmail.com
Wed Mar 19 00:15:59 UTC 2014
On Tue, Mar 18, 2014 at 8:12 AM, Sean Dague <sean at dague.net> wrote:
> On 03/18/2014 10:11 AM, Daniel P. Berrange wrote:
> > On Tue, Mar 18, 2014 at 07:50:15AM -0400, Davanum Srinivas wrote:
> >> Hi Team,
> >> We have 2 choices
> >> 1) Upgrade to libvirt 0.9.8+ (See  for details)
> >> 2) Enable UCA and upgrade to libvirt 1.2.2+ (see  for details)
> >> For #1, we received a patched deb from @SergeHallyn/@JamesPage and ran
> >> tests on it in review https://review.openstack.org/#/c/79816/
> >> For #2, @SergeHallyn/@JamesPage have updated UCA
> >> ("precise-proposed/icehouse") repo and we ran tests on it in review
> >> https://review.openstack.org/#/c/74889/
> >> For IceHouse, my recommendation is to request Ubuntu folks to push the
> >> patched 0.9.8+ version we validated to public repos, then we can can
> >> install/run gate jobs with that version. This is probably the smallest
> >> risk of the 2 choices.
> > If we've re-run the tests in that review enough times to be confident
> > we've had a chance of exercising the race conditions, then using the
> > patched 0.9.8 seems like a no-brainer. We know the current version in
> > ubuntu repos is broken for us, so the sooner we address that the better.
> >> As soon as Juno begins, we can switch 1.2.2+ on UCA and request Ubuntu
> >> folks to push the verified version where we can use it.
> > This basically re-raises the question of /what/ we should be testing in
> > the gate, which was discussed on this list a few weeks ago, and I'm not
> > clear that there was a definite decision in that thread
> > Testing the lowest vs highest is targetting two different scenarios
> > - Testing the lowest version demonstrates that OpenStack has not
> > broken its own code by introducing use of a new feature.
> > - Testing the highest version demonstrates that OpenStack has not
> > been broken by 3rd party code introducing a regression.
> > I think it is in scope for openstack to be targetting both of these
> > scenarios. For anything in-between though, it is upto the downstream
> > vendors to test their precise combination of versions. Currently though
> > our testing policy for non-python bits is "whatever version ubuntu
> > which may be neither the lowest or highest versions, just some arbitrary
> > version they wish to support. So this discussion is currently more of a
> > 'what ubuntu version should we test on' kind of decision
> I think testing 2 versions of libvirt in the gate is adding a matrix
> dimension that we currently can't really support. We're just going to
> have to pick one per release and be fine with it (at least for icehouse).
> If people want other versions tested, please come in with 3rd party ci
> on it.
> We can revisit the big test matrix at summit about the combinations
> we're going to actually validate, because with the various limitations
> we've got (concurrency limits, quota limits, upstream package limits,
> kinds of tests we want to run) we're going to have to make a bunch of
> compromises. Testing something new is going to require throwing existing
> stuff out of the test path.
I think this is definitely worth revisiting at the summit, but I think we
should move Juno to Libvirt 1.2.2+ as soon as possible instead of gating on
a 2 year old release, and at the summit we can sort out what the full test
matrix can be.
As a side note tripleo uses libvirt from Saucy (1.1.1) so moving to latest
libvirt would help support them.
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev