From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucas Meneghel Rodrigues Subject: Re: [Autotest] [AUTOTEST][PATCH 2/2] Add ability to call autotest client tests from kvm tests like a subtest. Date: Tue, 19 Jul 2011 11:18:04 -0300 Message-ID: <4E25921C.6010207@redhat.com> References: <2013195329.137124.1311078770999.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-autotest@redhat.com, kvm@vger.kernel.org, autotest@test.kernel.org, ldoktor@redhat.com, akong@redhat.com To: Jiri Zupka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22275 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803Ab1GSOSM (ORCPT ); Tue, 19 Jul 2011 10:18:12 -0400 In-Reply-To: <2013195329.137124.1311078770999.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.