----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Francesco Romani" <fromani@redhat.com> Cc: devel@ovirt.org Sent: Tuesday, February 24, 2015 3:16:57 PM Subject: Re: [ovirt-devel] [VDSM] about improved libvirt-python bindings
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 ;-)
My fault, poor wording. Both times (!). Let me try to clean up the mess. The module is supposed to be a transparent replacement much like pthreading. So, much like pthreading we'll simple do import pprint import libvirt_ovirt # naming can be improved libvirt_ovirt.monkey_patch() # from now own, API's the same and client code shouldn't be able to tell # the difference conn = libvirt_ovirt.openReadOnly('qemu:///system') pprint.pprint(conn.getAllDomainStats()) +++ So, no need for separate connection or special handling, much like no need for special treatment when we use pthreading instead of threading But this new module can also run side by side, meaning that monkey_patch can be minimized, and we can have both vanilla and enhanced API side by side. This is where my "complements and not replaces" come from. This can be useful if we have to run third-party code inside VDSM, which expects the plain libvirt API and not our cooked one. So we can have: conn.getAllDomainStats() # regular libvirt API conn.getAllDomainStatsMap() # own APIs which returns {UUID:dict()} side by side. Actually, it may be better to simplify things and just add new APIs. We'll still need monkeypatching, but this way is just the minimal amount to avoid awkward, clumsy interface. I hope is clearer now. If not, I'll post code samples :) -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani