[openstack-dev] [nova][infra] Ability to run newer QEMU in Gate jobs
Clark Boylan
cboylan at sapwetik.org
Tue Jan 19 17:42:05 UTC 2016
On Tue, Jan 19, 2016, at 09:32 AM, Kashyap Chamarthy wrote:
> Heya,
>
> Currently the live migration test job[1] is using relatively old version
> of QEMU (2.0 -- 2 years old, 17-APR-2014). And, libvirt 1.2.2
> (released on 02-MAR-2014). For libvirt, I realize there's an
> in-progress thread[2] to get to a state to run a bleeding edge libvirt.
>
> How can we go about bumping up QEMU to its newest stable release (2.5,
> DEC-2015)?
>
> Matt Riedemann tells me on IRC that multi-node live migration job is
> currently Ubuntu only, and to get a newer QEMU, it has to be added to
> Ubuntu Cloud Archive. It'd be useful to get that done. Who can help
> with it?
I would start by pushing a change to devstack or devstack-gate that
turns on cloud archive by default. Then libvirt and friends will all get
installed with the newer version and give you an idea of whether or not
the cloud archive is functional for us.
>
> It'll allow us to confirm our suspicion that a couple of Nova live
> migration bugs[3][4] are likely fixed with that version. Also it (the
> newer QEMU) has some additional debug logging capabilities which can
> help us with root cause analysis of some live migration issues.
Assuming nothing breaks you can then use the same change to iterate on
this to see if the bugs are corrected and get access to the richer logs.
>
>
> [1]
> https://jenkins05.openstack.org/job/gate-tempest-dsvm-multinode-live-migration/
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/079679.html
> [3] https://bugs.launchpad.net/nova/+bug/1524898 -- Volume based live
> migrtion aborted unexpectedly
> [4] https://bugs.launchpad.net/nova/+bug/1535232/ -- live-migration ci
> failure on nfs shared storage
>
Since both devstack and devstack-gate are self testing you can typically
do a first draft attempt at changes like this just by pushing a change,
letting the tests run, then checking the results. We may not want to go
with the simple change long term (as it likely won't cache packages
properly among other things), but it is very good at giving quick
results on whether or not it is viable at all.
Clark
More information about the OpenStack-dev
mailing list