----- Original Message ----- > From: "Francesco Romani" <[email protected]> > To: [email protected] > 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
