qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dor Laor <dlaor@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Glauber Costa <glommer@redhat.com>,
	qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: autotest (was Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT f80f9ec] Convert	machine	registration to use module initfunctions)
Date: Tue, 26 May 2009 12:54:36 +0300	[thread overview]
Message-ID: <4A1BBC5C.1010102@redhat.com> (raw)
In-Reply-To: <4A1BB698.7080805@codemonkey.ws>

Anthony Liguori wrote:
> Dor Laor wrote:
>> Anthony Liguori wrote:
>>> Avi Kivity wrote:
>>>> Anthony Liguori wrote:
>>>>> Autotest doesn't currently test the regressions that I want to test.  
>>>>
>>>> Which regressions do you want to test?
>>>
>>> For instance, we often have networking regressions.  In particular, 
>>> with the refactoring going on in slirp and tun/tap, I'd really like 
>>> to have an automated way to test slirp and tap with TCP 
>>> transmit/receive, and slirp redir.  I have something locally to do 
>>> this that I intend on posting in the next few days.
>>>
>> Current kvm autotest do test slirp. The step-files for guest 
>> installation open ssh/telnet access in order
>> to let the host reach them.
>> We trapped exactly this regression using autotest.
>
> What I want is a single test that completes quickly.  This means a 
> preconfigured guest that I can run a quick test case against.
>
> Installation tests a lot of things.  I'm looking for more targeted tests.
No doubt unit tests and some tools run manually are the best.
Nevertheless, the projects needs fully automated test framework that 
test it all.
Even today you do not have to go through the guest install each time.
Guest images are not erased after the install and autotest itself spawn 
additional
tests over this image. Even a VM can be kept alive at the end of a test, 
waiting for
additional tests to be executed over it.

In the future, I envision that you can go to auto-serv web interface, 
manually pick
a host and a test case and run it. The test will have built-in 
dependencies, and
if the VM is installed and alive it would just run the test as quick as 
possible.
Otherwise it will automatically do the dependency chain (or prompt for it).
>
>>> I wouldn't require kvm-autotest, but I'd like to have an interest 
>>> set of unit tests that are then usable within kvm-autotest.  Once we 
>>> have that, asking politely for tests to be written I think is quite 
>>> reasonable.
>> Some features are easily tested using a large framework, for example 
>> migration, slirp, time drift, etc.
>> In addition kvm's tests unit tests, qemu-io and similar should be 
>> written too in order to test various cases that
>> are only reasonable to be found using low level operations.
>> No doubt all of the unit tests should be executed from autotest.
>
> Yup, I agree 100%.
>
> Regards,
>
> Anthony Liguori

  reply	other threads:[~2009-05-26  9:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200905211348.n4LDmnYd025976@d01av04.pok.ibm.com>
2009-05-21 22:36 ` [Qemu-devel] Re: [Qemu-commits] [COMMIT f80f9ec] Convert machine registration to use module initfunctions Paul Brook
2009-05-21 22:50   ` Glauber Costa
2009-05-22  1:34     ` Anthony Liguori
2009-05-22  1:49       ` Glauber Costa
2009-05-22  2:00         ` Anthony Liguori
2009-05-23 14:22       ` autotest (was Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT f80f9ec] Convert machine registration to use module initfunctions) Dor Laor
2009-05-24 19:46         ` Anthony Liguori
2009-05-24 20:50           ` Avi Kivity
2009-05-26  8:10             ` Anthony Liguori
2009-05-26  9:17               ` Avi Kivity
2009-05-26  9:17               ` Dor Laor
2009-05-26  9:30                 ` Anthony Liguori
2009-05-26  9:54                   ` Dor Laor [this message]
2009-05-22  1:21   ` [Qemu-devel] Re: [Qemu-commits] [COMMIT f80f9ec] Convert machine registration to use module initfunctions Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A1BBC5C.1010102@redhat.com \
    --to=dlaor@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=glommer@redhat.com \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).