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. > 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. I haven't also a good idea for this, the only thing is we give a try, thanks for sharing your ideas with me.
Alex->Lucas, have you other advice? thanks. Regards, Alex > > Just some ideas. > _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
