Maipo should also use the local qemu clone

[ghost]

http://tracker.ceph.com/issues/10975 Fixes: #10975

Signed-off-by: Loic Dachary loic@dachary.org

[ghost]

@jdurgin is this going in the right direction ?

[jdurgin]

Yeah, it's a good start. I'm not sure exactly what other distros/versions we have in the labs at this point. There may be centos too.

[loic-bot]

SUCCESS: the output of run-make-check.sh on centos-centos7 for 7006dbe is http://paste2.org/_cV02zZvw

Sent from GH.

[ghost]

@jdurgin Shouldn't we be using the clone depending on the version of qemu available on the system rather than the lsb_release code name ?

[jdurgin]

That's what I thought originally, but then looked at how many backports there are in a rhel6 qemu, and concluded the version number was meaningless to compare to upstream versions

[ghost]

@jdurgin I must be missing something. As far as I understand (and I don't understand much, sorry about that ;-), the test depends on the installed qemu being run. That's why I thought something like

$ qemu-system-x86_64 --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.10), Copyright (c) 2003-2008 Fabrice Bellard

and extracting the version number from that would be the most reliable way to figure out where to fetch the tests.

[jdurgin]

@dachary The trouble is that distro version numbers don't correspond well with upstream ones for qemu in particular. CentOS 6 for example has qemu 0.12.something, but it has 4000 patches on top of upstream 0.12, which make it behave more like upstream 1.0.

[ghost]

@jdurgin now I get it. First time I heard of such a problem, interesting :-) In a nutshell, this patch is ok to merge and we can add more releases as we test more of them ? Or should we do the opposite: test more platforms and update the patch until there is enough coverage ?

[jdurgin]

@dachary Merged, let's reopen the bug if there are failures on master. Once we've seen a few passing runs, we can backport to each stable branch.

[ghost]

@jdurgin ack