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

[Lucas Meneghel Rodrigues <lmr@redhat.com>]

On Tue 19 Jul 2011 09:32:51 AM BRT, Jiri Zupka wrote:
>>
>> 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).

^ Or, in other words, 'merge' the client and the server program, so 
we'd have a single, unified API to write tests, and any . This is 
something that Martin Bligh wanted to get done in autotest.

However, it is pretty major work going on. I really like the idea, so 
let's evaluate it carefully
 
> 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.

Although I might be way off, I saw stuff on beijing's tree (I think it 
is cross_host_utilities or something) that could help to implement this 
option.

> 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.

My personal preference would be to unify server and client, so 2). 
However, given that it is *major* work, maybe 3) is better.