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.
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani