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

[Nir Soffer]

----- Original Message -----
> From: "Francesco Romani" <fromani at redhat.com>
> To: devel at ovirt.org
> Sent: Wednesday, February 18, 2015 2:53:17 PM
> Subject: [ovirt-devel] [VDSM] about improved libvirt-python bindings
> 
> 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.
> 
> 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.
> 
> https://github.com/mojaves/libvirt-python-ovirt
> 
> It monkeys-patch some APIs and replace them with VDSM-crafted ones.
> If we have enough of monkey patching, it is even easier to just add new APIs
> instead of replacing them.
> 
> 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.

Without looking in the details, this sounds like a bad idea.

Your effort should go to improving libvirt-python bindings, which all
libvirt users can benefit from, and not creating a special bindings for
ovirt.

Nir