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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
