[ovirt-devel] [VDSM] about improved libvirt-python bindings

[Dan Kenigsberg]

On Tue, Feb 24, 2015 at 05:40:07AM -0500, Francesco Romani wrote:
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Francesco Romani" <fromani at redhat.com>
> > Cc: devel at ovirt.org
> > Sent: Tuesday, February 24, 2015 11:19:20 AM
> > Subject: Re: [ovirt-devel] [VDSM] about improved libvirt-python bindings
> > 
> > On Wed, Feb 18, 2015 at 07:53:17AM -0500, Francesco Romani wrote:
> > > Hi,
> > > 
> > > during my sampling overhaul effort I faced various times a mismatch between
> > > what the libvirt-python API offers for bulk stats and what VDSM needs.
> > > 
> > > The return value of bulk stats is a something like
> > > 
> > > [(dom1, {dict_of_bulk_stats1}), {dom2, {dict_of_bulk_stats2}), ...]
> > > 
> > > While VDSM almost all the times really wants to use
> > > 
> > > { dom_uuid_1: dict_of_bulk_stats_1, dom_uuid_2: dict_of_bulk_stats_2 }
> > > 
> > > translation is trivial to be coded, but bulk stats retrieval is quite
> > > always in the hot path. Moreover, this is just wasteful.
> > 
> > How big is the waste?
> 
> Will provide hard numbers (and possibly pretty graphs)
>  
> > > But in general, there will always be a not-perfect match from
> > > libvirt-python
> > > and VDSM needs. This is expected: libvirt-python needs to be more generic.
> > > 
> > > So, I coded a Proof of Concept extension module which *complements*
> > > and not *replaces* the libvirt-python API.
> > 
> > Does it require Vdsm to hold two open connections to libvirtd? [...]
> 
> Nope, it is intended as transparent replacement, much like our pthreading
> does for threading standard module.

ah, ok. please read again your "I coded a Proof...API" sentence to see
why I was confused ;-)

> [...]
> > > It was a nice and fun hack, but now, the question is: is that a concept
> > > worth developing further? Do we want to use and depend on this module?
> > > 
> > > I believe that with such a buffer we can gain some agility with respect
> > > to libvirt plans and needs, and the maintainership cost _seems_ fairly low.
> > > 
> > > Thoughts welcome.
> > 
> > To me, adding this module seems quite expensive: new ovirt project,
> > inclusion in fedora/el/debian, versioning and release-engineering
> > hassle.
> 
> Right, but much of this cost should be bootstrap, not recurring, right?
> Not trying to push things, just to assess the cons.

Well, maintaining another package per distribution has some recurrent
costs.  It has to be rebuilt on each ovirt release (assuming no urgent
security bugs), and there might be unexpected needs to recompile (python
change, libvirt upgrade).

Regards,
Dan.