On 03/29/2012 10:53 AM, Alex Jia wrote: > Any idea about this? > > Thanks, > Alex > > ----- Original Message ----- > From: "Alex Jia"<[email protected]> > To: "Chris Evich"<[email protected]> > Cc: [email protected] > 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 with some kind of C&C base-class which tests access and instantiate by way of a VM method. However, it's accomplished, I think it would be useful to attempt to generalize/abstract the backend mechanics. Clearly this won't be possible for every functional requirement. Where possible, it would be helpful to try. Just some ideas. -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
