On 03/30/2012 06:08 AM, Alex Jia wrote: > On 03/29/2012 11:47 PM, Chris Evich wrote: >> On 03/29/2012 10:53 AM, Alex Jia wrote: >>> Any idea about this? >>> >>> Thanks, >>> Alex >>> >>> ----- Original Message ----- >>> From: "Alex Jia"<a...@redhat.com> >>> To: "Chris Evich"<cev...@redhat.com> >>> Cc: autotest@test.kernel.org >>> Sent: Wednesday, March 28, 2012 11:47:53 PM >>> Subject: Re: [Autotest] [libvirt-autotest] New requirement >>> >>> On 03/28/2012 09:14 PM, Chris Evich wrote: >>>> On 03/28/2012 06:23 AM, Alex Jia wrote: >>>>>> I guess the best thing here is to remove libvirt_monitor.py >>>>>> altogether >>>>>> and introduce a virsh.py file, and call it a day. >>>>> I haven't seen other feedback by now, if it's a final solution, I will >>>>> commit patches to >>>>> change these or others want to do it, also okay for me: >>>>> >>>>> 1. remove libvirt_monitor.py >>>>> 2. introduce a virsh.py then move all of virsh wrapper into it >>>>> 3. also need to change previous cases to follow these modification >>>>> >>>>> Please let me know early if you have a better suggestion. >>>>> >>>>> Regards, >>>>> Alex >>>> I was thinking very broadly of the definition of 'monitor', I know it's >>> Yeah, I also considered this ago, I want to put some interactive methods >>> with guest >>> into the 'monitor' module such as remotely login guest and get some >>> informations >>> from the guest, however, these should be common utilities, so we may >>> move them >>> into utilities library. >>>> >>>> not an exact fit. Virsh.py is fine by me also. My preference would be >>>> that test-module code not use it directly, but go through the VM class. >>> Need we a VIRSH class in virsh.py? it should be more clear, but it has >>> another issue, >>> we can't directly call virsh_* function in test cases, it requires to >>> instantiated VIRSH >>> class firstly then call virsh_* function, if so, it's not convenient for >>> writing test cases, >>> maybe, we may use python static method? I'm not sure about this. >>>> >>>> That will let us better weather underlying virsh changes and >>>> compatibility issues. However, getting the code moved to a new module >>>> is the first step, and it will un-cluter libvirt_vm.py quite a bit. >>>> Thanks! >>> For new libvirt_vm.py, I'm thinking to only reserve 'VM' class section >>> then move others >>> virsh wrapper into virsh.py, in addition, we should move >>> 'service_libvirtd_control' common >>> function into virt_utils.py and remove libvirt_[start|stop|restart], of >>> course, also need to >>> change test cases. >>> >>> Thanks for your comment, >>> Alex >>>> >>> >> >> Hi, >> >> Yep, a virsh class sounds good, perhaps following a singleton pattern. >> For tests, perhaps come up > I'm not sure singleton pattern is fine for us, but I will try it.
If it's no good don't sweat it, ideas are cheap :) It's more important that it works for you than adheres to some dogma. -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
