<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 3:43 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 03/18/2014 08:15 PM, Joe Gordon wrote:<br>
><br>
><br>
><br>
> On Tue, Mar 18, 2014 at 8:12 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>>> wrote:<br>
><br>
> On 03/18/2014 10:11 AM, Daniel P. Berrange wrote:<br>
> > On Tue, Mar 18, 2014 at 07:50:15AM -0400, Davanum Srinivas wrote:<br>
> >> Hi Team,<br>
> >><br>
> >> We have 2 choices<br>
> >><br>
> >> 1) Upgrade to libvirt 0.9.8+ (See [1] for details)<br>
> >> 2) Enable UCA and upgrade to libvirt 1.2.2+ (see [2] for details)<br>
> >><br>
> >> For #1, we received a patched deb from @SergeHallyn/@JamesPage<br>
> and ran<br>
> >> tests on it in review <a href="https://review.openstack.org/#/c/79816/" target="_blank">https://review.openstack.org/#/c/79816/</a><br>
> >> For #2, @SergeHallyn/@JamesPage have updated UCA<br>
> >> ("precise-proposed/icehouse") repo and we ran tests on it in review<br>
> >> <a href="https://review.openstack.org/#/c/74889/" target="_blank">https://review.openstack.org/#/c/74889/</a><br>
> >><br>
> >> For IceHouse, my recommendation is to request Ubuntu folks to<br>
> push the<br>
> >> patched 0.9.8+ version we validated to public repos, then we can can<br>
> >> install/run gate jobs with that version. This is probably the<br>
> smallest<br>
> >> risk of the 2 choices.<br>
> ><br>
> > If we've re-run the tests in that review enough times to be confident<br>
> > we've had a chance of exercising the race conditions, then using the<br>
> > patched 0.9.8 seems like a no-brainer. We know the current version in<br>
> > ubuntu repos is broken for us, so the sooner we address that the<br>
> better.<br>
><br>
><br>
><br>
> ++<br>
><br>
><br>
> ><br>
> >> As soon as Juno begins, we can switch 1.2.2+ on UCA and request<br>
> Ubuntu<br>
> >> folks to push the verified version where we can use it.<br>
><br>
><br>
> ++<br>
><br>
><br>
> ><br>
> > This basically re-raises the question of /what/ we should be<br>
> testing in<br>
> > the gate, which was discussed on this list a few weeks ago, and<br>
> I'm not<br>
> > clear that there was a definite decision in that thread<br>
> ><br>
> ><br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/027734.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-February/027734.html</a><br>
> ><br>
> > Testing the lowest vs highest is targetting two different scenarios<br>
> ><br>
> > - Testing the lowest version demonstrates that OpenStack has not<br>
> > broken its own code by introducing use of a new feature.<br>
> ><br>
> > - Testing the highest version demonstrates that OpenStack has not<br>
> > been broken by 3rd party code introducing a regression.<br>
> ><br>
> > I think it is in scope for openstack to be targetting both of these<br>
> > scenarios. For anything in-between though, it is upto the downstream<br>
> > vendors to test their precise combination of versions. Currently<br>
> though<br>
> > our testing policy for non-python bits is "whatever version ubuntu<br>
> ships",<br>
> > which may be neither the lowest or highest versions, just some<br>
> arbitrary<br>
> > version they wish to support. So this discussion is currently more<br>
> of a<br>
> > 'what ubuntu version should we test on' kind of decision<br>
><br>
> I think testing 2 versions of libvirt in the gate is adding a matrix<br>
> dimension that we currently can't really support. We're just going to<br>
> have to pick one per release and be fine with it (at least for<br>
> icehouse).<br>
><br>
> If people want other versions tested, please come in with 3rd party ci<br>
> on it.<br>
><br>
> We can revisit the big test matrix at summit about the combinations<br>
> we're going to actually validate, because with the various limitations<br>
> we've got (concurrency limits, quota limits, upstream package limits,<br>
> kinds of tests we want to run) we're going to have to make a bunch of<br>
> compromises. Testing something new is going to require throwing existing<br>
> stuff out of the test path.<br>
><br>
><br>
> I think this is definitely worth revisiting at the summit, but I think<br>
> we should move Juno to Libvirt 1.2.2+ as soon as possible instead of<br>
> gating on a 2 year old release, and at the summit we can sort out what<br>
> the full test matrix can be.<br>
><br>
> As a side note tripleo uses libvirt from Saucy (1.1.1) so moving to<br>
> latest libvirt would help support them.<br>
<br>
</div></div>Honestly, given that we've been trying to get a working UCA for 6<br>
months, I'm really not thrilled by the idea of making UCA part of our<br>
gate. Because it's clearly not at the same level of testing as the base<br>
distro. I think this will be even more so with UCA post 14.04 release,<br>
as that's designed as a transitional stage to get you to 14.04.<br>
<br>
As has been demonstrated, Canonical's testing systems are clearly not<br>
finding the same bugs we are finding in their underlying packages.<br>
<br>
I think the libvirt 1.2+ plan should be moving Juno to 14.04 as soon as<br>
we can get that stable. That will bring in a whole fresh OS, kernel,<br>
etc. And we recenter our testing on that LTS going forward.<br></blockquote><div><br></div><div>Sounds like a good plan to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
Samsung Research America<br>
<a href="mailto:sean@dague.net">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>