From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfbKW-0004M0-9C for qemu-devel@nongnu.org; Tue, 27 Dec 2011 13:00:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RfbKV-0000gx-7L for qemu-devel@nongnu.org; Tue, 27 Dec 2011 13:00:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfbKV-0000gp-01 for qemu-devel@nongnu.org; Tue, 27 Dec 2011 13:00:51 -0500 Message-ID: <4EFA07D3.60204@redhat.com> Date: Tue, 27 Dec 2011 16:00:51 -0200 From: Lucas Meneghel Rodrigues MIME-Version: 1.0 References: <4EEF70B4.3070109@us.ibm.com> <4EF73EF5.8050606@redhat.com> <4EF88EC0.8020301@codemonkey.ws> <4EF8FC88.70809@redhat.com> <4EF9E2CA.1020401@codemonkey.ws> <4EF9EB27.7050707@redhat.com> <4EF9F4EE.6080106@codemonkey.ws> In-Reply-To: <4EF9F4EE.6080106@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: dlaor@redhat.com, Gerd Hoffmann , Avi Kivity , Stefan Hajnoczi , qemu-devel On 12/27/2011 02:40 PM, Anthony Liguori wrote: > On 12/27/2011 09:58 AM, Avi Kivity wrote: >> On 12/27/2011 05:22 PM, Anthony Liguori wrote: >>> >>> The infrastructure assumes that you have a full OS available in the >>> guest. The tests are written in Python and make a variety of >>> assumptions. To my knowledge, it's not very practical to build a >>> busybox environment with Python embedded in it. >> >> You could move whatever infrastructure qemu-test uses to kvm-autotest, >> at which point kvm-autotest will know everything qemu-test knows. But >> there's zero reason to do that, autotest is designed to drive external >> tests and in fact most of the tests it supports are not in the autotest >> repository. > > Yes. I think having a qemu-test driver for kvm-autotest that knows > enough to invoke the qemu-tests and integrate the results in autotest > results reporting is the right thing to do. I am happy with that too. There's a slight inaccuracy when you've mentioned that KVM autotest mandates guest OS installs to perform tests. It's possible to use pre-installed guest images, making the time of execution of a test job shorter. But anyway, your reasoning is sound. Considering that's not a lot of code overlap between the 2 infrastructures, as long as we can make them interact well, all is good. Plus, the way qemu-test is structured integrates well with the workflow most qemu developers are used to. In my point of view, it's a win-win situation, as I expect more developers to invest some time writing test automation. Ideally it would be nice to have more people contributing tests to both qemu-test *and* kvm autotest, no doubt, but this is something we (kvm autotest team) still have to figure how to accomplish.