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