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

[Dan Kenigsberg]

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?

> 
> 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? I'm a bit
worried about possible races and inconsistencies that can pop up due to
this. I'm not expecting huge troubles, just the possiblity that a future
vdsm developer would assume that dom1 and dom1prime are the same since
they represent the same VM, while in case, they come via a different
virconnection and has different attributes.

> 
> 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.

To me, adding this module seems quite expensive: new ovirt project,
inclusion in fedora/el/debian, versioning and release-engineering
hassle. To support the idea, I'd prefer to see a measureable improvement
in architecture or performence, that still alludes me.