Re: [Autotest] [AUTOTEST][KVM] [PATCH 2/2] Add ability to call autotest client tests from kvm tests like a subtest.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Lukas,

> Hi Jiri, after reviewing the code I have comments, similar to
> Cleber's:
> 
> On Fri, Apr 29, 2011 at 10:59 AM, Jiří Župka <jzupka@xxxxxxxxxx>
> wrote:
> > Example run autotest/client/netperf2 like a server.
> 
> ... snip
> 
> > diff --git a/client/tests/kvm/tests/subtest.py
> > b/client/tests/kvm/tests/subtest.py
> > new file mode 100644
> > index 0000000..3b546dc
> > --- /dev/null
> > +++ b/client/tests/kvm/tests/subtest.py
> > @@ -0,0 +1,43 @@
> > +import os, logging
> > +from autotest_lib.client.virt import virt_utils, virt_test_utils,
> > kvm_monitor
> > +from autotest_lib.client.bin import job
> > +from autotest_lib.client.bin.net import net_utils
> > +
> > +
> > +def run_subtest(test, params, env):
> > + """
> > + Run an autotest test inside a guest and subtest on host side.
> > + This test should be substitution netperf test in kvm.
> > +
> > + @param test: kvm test object.
> > + @param params: Dictionary with test parameters.
> > + @param env: Dictionary with the test environment.
> > + """
> > + vm = env.get_vm(params["main_vm"])
> > + vm.verify_alive()
> > + timeout = int(params.get("login_timeout", 360))
> > + session = vm.wait_for_login(timeout=timeout)
> > +
> > + # Collect test parameters
> > + timeout = int(params.get("test_timeout", 300))
> > + control_path = os.path.join(test.bindir, "autotest_control",
> > + params.get("test_control_file"))
> > + control_args = params.get("test_control_args")
> > + outputdir = test.outputdir
> > +
> > + guest_ip = vm.get_address()
> > + host_ip = net_utils.network().get_corespond_local_ip(guest_ip)
> > + if not host_ip is None:
> > + control_args = host_ip + " " + guest_ip
> > +
> > + guest = virt_utils.Thread(virt_test_utils.run_autotest,
> > + (vm, session, control_path, control_args,
> > + timeout, outputdir, params))
> > + guest.start()
> > +
> > + test.runsubtest("netperf2", tag="server", server_ip=host_ip,
> > + client_ip=guest_ip, role='server')
> 
> ^ This really should be made generic, since as Cleber mentioned,
> calling this test run_subtest wouldn't cut for cases where we run
> something other than netperf2. So things that started coming to my
> mind:
> 
> * We could extend the utility function to run autotest tests on a
> guest in a way that it can accept a string with the control file
> contents, rather than just an existing control file. This way we'd be
> more free to run arbitrary control code in guests, while of course
> keeping the ability to use existing control files;
> * We could actually create an Autotest() class abstraction, very much
> like what we have in server control files, such as
> 
> auto_vm1 = virt_utils.Autotest(vm1) # This would install autotest in a
> VM and wait for further commands
> 
> control = "job.run_test('sleeptest')"
> 
> auto_vm1.run_control(control) # This would run sleeptest and bring
> back the results to the host

I'm thinking about this feature and there is some choice:
 1) We can do another separate interface for this feature in autotest/client.
       - I think, not good way because there is to much (useless, duplicate) code.
 2) Move Autotest.py from server part to client part and 
     a) Write interface for package hosts which extend virt_vm.py and aexpect.py 
         to work as hosts part in server.
           - This isn't enough generic you can't run test on virt machine and another 
             bare metal host.
     b) Move hosts part from server to client part. This add ability cliet part of test
         to start autotest test on others machines. 
          - Is this way good? This is most generic way how to do this, but this changes
            should change way of using autotest. When server starts test on client 
            machines (bare metal, virt).

May be we should think about place of virt in autotest infrastructure.. If there is test 
which is multimechine, generic and should be run on bare metal and virt machine 
with no problem. 
1*) Then there should be way how to start virtual machine from server part 
    but with capabilities like is in kvm test. (because there is lot of good features
    like automatic installing of virtual machine, etc..)
2*) Or we can move some of part from server to client part (autotest.py, hosts) to
    allow client part of test start autotest on virt machine and on bare metal machine.
3*) Or we should think about writing tests. This mean no changes in autotest structure 
    but changes in tests structure. Client part should have test to only start virt machine 
    and server controls of starting tests on this infrastructure. This mean move 
    some of (kvm, virt) test server part (virt/tests/multicast, virt/tests/netperf).
    May be there should be /server/tests/virtprepare. This way is posible start kvm machine.

I have done part (2) and I have done some part of part (b) 70%, but I'm not sure if this is 
good way how to do this. This is most generic but... I'm going to do changes way (2b) but 
I think that way (3*) is most clean way how to do this.

Jiří

> 
> It's a matter to see how this is modeled for server side control
> files... I believe this could be cleaner and help us a lot...
> 
> In other comments, please use the idiom:
> 
> if foo is not None:
> 
> Across all places where we compare a variable with None, because it's
> easier to understand the intent right away and it's on the
> CODING_STYLE document.
> 
> --
> Lucas
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux