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. _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
