From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucas Meneghel Rodrigues Subject: Re: [PATCH 05/11] virt: Introducing libvirt VM class Date: Thu, 13 Oct 2011 14:26:31 -0300 Message-ID: <4E971F47.6010005@redhat.com> References: <1318367237-26081-1-git-send-email-lmr@redhat.com> <1318367237-26081-6-git-send-email-lmr@redhat.com> <20111012081447.GC9848@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: autotest@test.kernel.org, kvm@vger.kernel.org To: "Daniel P. Berrange" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37401 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755655Ab1JMR0d (ORCPT ); Thu, 13 Oct 2011 13:26:33 -0400 In-Reply-To: <20111012081447.GC9848@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/12/2011 05:14 AM, Daniel P. Berrange wrote: > On Tue, Oct 11, 2011 at 06:07:11PM -0300, Lucas Meneghel Rodrigues wrote: >> This is a first attempt at providing a libvirt VM class, >> in order to implement the needed methods for virt testing. >> With this class, we will be able to implement a libvirt >> test, that behaves similarly to the KVM test. >> >> As of implementation details, libvirt_vm uses virsh >> (a userspace program written on top of libvirt) to >> do domain start, stop, verification of status and >> other common operations. The reason why virsh was >> used is to get more coverage of the userspace stack >> that libvirt offers, and also to catch issues that >> virsh users would catch. > > Personally I would have recommended that you use the libvirt Python API. > virsh is a very thin layer over the libvirt API, which mostly avoidse > adding any logic of its own, so once it has been tested once, there's > not much value in doing more. By using the Python API directly, you will > be able todo more intelligent handling of errors, since you'll get the > full libvirt python exception object instead of a blob of stuff on stderr. > Not to mention that it is so much more efficient, and robust against > any future changes in virsh. Thanks Daniel. We've discussed about that quite a few times during the development of the code. The plan is to just add methods that will do the same as the API counterpart moving forward, so we can test both the think layer that is virsh and the py API. We just wanted to focusing in one implementation to get something functional first. We'll keep you guys posted about progress on py bindings. Cheers, Lucas