[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. -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
Hi, as far as I understand this would make it easier to implement/use upstreams(libvirt) existing python-bindings in ovirt? in this case, I think this is a huge improvement. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Hi, ----- Original Message -----
From: "Sven Kieske" <s.kieske@mittwald.de> To: devel@ovirt.org Sent: Wednesday, February 18, 2015 2:12:15 PM Subject: Re: [ovirt-devel] [VDSM] about improved libvirt-python bindings
Hi,
as far as I understand this would make it easier to implement/use upstreams(libvirt) existing python-bindings in ovirt?
in this case, I think this is a huge improvement.
My point here is libvirt and oVirt have slightly misaligned path. This is absolutely expected and OK, since libvirt should and can not only serve the purposes of oVirt, but a much broader scope! Nowadays we (oVirt, VDSM in particular) just consume the libvirt python API and we fix the mismatches in our own application code. Most often is a no-brainer, sometimes is annoying. Especially also given the recent efforts to improve and enhance the scalability of VDSM, we may need (today or tomorrow) a different approach. The one I'm offering is *a* potential solution (IMVHO pretty fitting), hence my discussion here :) -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
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.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Francesco Romani" <fromani@redhat.com> Cc: devel@ovirt.org Sent: Tuesday, February 24, 2015 11:19:20 AM Subject: Re: [ovirt-devel] [VDSM] about improved libvirt-python bindings
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?
Will provide hard numbers (and possibly pretty graphs)
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. [...]
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.
Right, but much of this cost should be bootstrap, not recurring, right? Not trying to push things, just to assess the cons.
To support the idea, I'd prefer to see a measureable improvement in architecture or performence, that still alludes me.
Right, will work on that direction. Thanks and bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
On Tue, Feb 24, 2015 at 05:40:07AM -0500, Francesco Romani wrote:
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Francesco Romani" <fromani@redhat.com> Cc: devel@ovirt.org Sent: Tuesday, February 24, 2015 11:19:20 AM Subject: Re: [ovirt-devel] [VDSM] about improved libvirt-python bindings
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?
Will provide hard numbers (and possibly pretty graphs)
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 ;-)
[...]
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.
Right, but much of this cost should be bootstrap, not recurring, right? Not trying to push things, just to assess the cons.
Well, maintaining another package per distribution has some recurrent costs. It has to be rebuilt on each ovirt release (assuming no urgent security bugs), and there might be unexpected needs to recompile (python change, libvirt upgrade). Regards, Dan.
----- 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
----- Original Message -----
From: "Francesco Romani" <fromani@redhat.com> To: devel@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
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: "Francesco Romani" <fromani@redhat.com> Cc: devel@ovirt.org Sent: Tuesday, February 24, 2015 3:24:30 PM Subject: Re: [ovirt-devel] [VDSM] about improved libvirt-python bindings
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.
Well, my problem was just that the API was different enough to make me think that it was unsuitable for libvirt upstream. But worth trying to upstream first, definitely. -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
participants (4)
-
Dan Kenigsberg -
Francesco Romani -
Nir Soffer -
Sven Kieske