[vdsm][mom][jsonrpc] new VDSM interface for MOM
Hi everyone, I'm working to brush up and enhance my old hack https://gerrit.ovirt.org/#/c/37827/1 That patch adds a new MOM interface, to talk with VDSM using the RPC interface. On top of that, I want to make efficient use of VDSM API (avoid redundant call, possibly issuing only one getAllVmStats call and caching the results, and so forth) Next step will be to backport optimizations to current vdsmInterface. Or maybe, even replacing the new vdsminterface with the new one I'm developing :) I'd like to use the blessed JSON-RPC interface, but what's the recommended way to do that? What is (or will be!) the official recommended VDSM external client interface? I thought about patch https://gerrit.ovirt.org/#/c/39203/ But my _impression_ is that patch will depend on VDSM's internal reactor, thus is not very suitable to be used into an external process. -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
On Mon, May 11, 2015 at 04:28:11AM -0400, Francesco Romani wrote:
Hi everyone,
I'm working to brush up and enhance my old hack https://gerrit.ovirt.org/#/c/37827/1
That patch adds a new MOM interface, to talk with VDSM using the RPC interface.
The benefit of bulk calls is clear. Can you explain about the benefit of using RPC instead of vdsm's API.py layer? (I can think of one or two, but it's less clear-cut). But what troubles me more is why are they related?
On top of that, I want to make efficient use of VDSM API (avoid redundant call, possibly issuing only one getAllVmStats call and caching the results, and so forth)
Next step will be to backport optimizations to current vdsmInterface. Or maybe, even replacing the new vdsminterface with the new one I'm developing :)
I'd like to use the blessed JSON-RPC interface, but what's the recommended way to do that? What is (or will be!) the official recommended VDSM external client interface?
I thought about patch https://gerrit.ovirt.org/#/c/39203/
But my _impression_ is that patch will depend on VDSM's internal reactor, thus is not very suitable to be used into an external process.
I am baffled as well. Yeela, could you add to this patch a functional test, which expects a running Vdsm, and uses vdsm.jsonrpcvdscli to connect to it and run a simple getCaps verb? Regards, Dan.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Francesco Romani" <fromani@redhat.com>, alitke@redhat.com, ykaplan@redhat.com Cc: devel@ovirt.org Sent: Monday, May 11, 2015 4:59:01 PM Subject: Re: [ovirt-devel] [vdsm][mom][jsonrpc] new VDSM interface for MOM
On Mon, May 11, 2015 at 04:28:11AM -0400, Francesco Romani wrote:
Hi everyone,
I'm working to brush up and enhance my old hack https://gerrit.ovirt.org/#/c/37827/1
That patch adds a new MOM interface, to talk with VDSM using the RPC interface.
The benefit of bulk calls is clear. Can you explain about the benefit of using RPC instead of vdsm's API.py layer? (I can think of one or two, but it's less clear-cut).
The biggest benefit if for vdsmd - if momd is made again a separate process, the thread count in vdsmd will plummet down to the minimum. Then of course MOM will need more fixes, but that can be done asynchronously with respect to 3.6.x Besides, I'd REALLY like to have just one public API layer, which should be *RPC, mostly because MOM can be ported to *RPC, while Engine cannot be ported to API.py :) I don't have a compelling reason to do this, except the horrible memories of the recent getVMList/onlyUUID incident, which will not fade away easily.
But what troubles me more is why are they related?
The two concepts "bulk API" and "RPC interface" are indeed orthogonal and one does not imply or require the other. I *choose* to reimplement the individual API on top of a single bulk call to optimize the performance (actually, to measure and verify the expected gains), and I did that in the new interface, which can trivially run in parallel with the old one. The problem is if I "just" add and export a new bulk call, then the rest of MOM needs to be updated, like I did in https://gerrit.ovirt.org/#/c/37827/6 https://gerrit.ovirt.org/#/c/39754/1 https://gerrit.ovirt.org/#/c/39753/1 Problem is these changes are much more invasive - and controversial, than just hide everything inside the Hypervisor interface like I'm doing in 37827 Bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
On 11/05/15 04:28 -0400, Francesco Romani wrote:
Hi everyone,
I'm working to brush up and enhance my old hack https://gerrit.ovirt.org/#/c/37827/1
That patch adds a new MOM interface, to talk with VDSM using the RPC interface. On top of that, I want to make efficient use of VDSM API (avoid redundant call, possibly issuing only one getAllVmStats call and caching the results, and so forth)
Next step will be to backport optimizations to current vdsmInterface. Or maybe, even replacing the new vdsminterface with the new one I'm developing :)
I'd like to use the blessed JSON-RPC interface, but what's the recommended way to do that? What is (or will be!) the official recommended VDSM external client interface?
I thought about patch https://gerrit.ovirt.org/#/c/39203/
But my _impression_ is that patch will depend on VDSM's internal reactor, thus is not very suitable to be used into an external process.
I've written my own extremely crude client using the stomp library. Nir also has a patch [1] on gerrit to do this. Maybe he can provide some insight. It'd be nice if the vdsm-yajsonrpc package could provide a full-featured client class that could be easily integrated into projects like MOM. [1] https://gerrit.ovirt.org/#/c/35181/ -- Adam Litke
On Wed, May 13, 2015 at 9:52 PM, Adam Litke <alitke@redhat.com> wrote:
On 11/05/15 04:28 -0400, Francesco Romani wrote:
Hi everyone,
I'm working to brush up and enhance my old hack https://gerrit.ovirt.org/#/c/37827/1
That patch adds a new MOM interface, to talk with VDSM using the RPC interface. On top of that, I want to make efficient use of VDSM API (avoid redundant call, possibly issuing only one getAllVmStats call and caching the results, and so forth)
Next step will be to backport optimizations to current vdsmInterface. Or maybe, even replacing the new vdsminterface with the new one I'm developing :)
I'd like to use the blessed JSON-RPC interface, but what's the recommended way to do that? What is (or will be!) the official recommended VDSM external client interface?
I thought about patch https://gerrit.ovirt.org/#/c/39203/
But my _impression_ is that patch will depend on VDSM's internal reactor, thus is not very suitable to be used into an external process.
I've written my own extremely crude client using the stomp library. Nir also has a patch [1] on gerrit to do this. Maybe he can provide some insight. It'd be nice if the vdsm-yajsonrpc package could provide a full-featured client class that could be easily integrated into projects like MOM.
I will try to provide simple client for people to use.
[1] https://gerrit.ovirt.org/#/c/35181/
-- Adam Litke
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 13/05/15 22:53 +0200, Piotr Kliczewski wrote:
On Wed, May 13, 2015 at 9:52 PM, Adam Litke <alitke@redhat.com> wrote:
On 11/05/15 04:28 -0400, Francesco Romani wrote:
Hi everyone,
I'm working to brush up and enhance my old hack https://gerrit.ovirt.org/#/c/37827/1
That patch adds a new MOM interface, to talk with VDSM using the RPC interface. On top of that, I want to make efficient use of VDSM API (avoid redundant call, possibly issuing only one getAllVmStats call and caching the results, and so forth)
Next step will be to backport optimizations to current vdsmInterface. Or maybe, even replacing the new vdsminterface with the new one I'm developing :)
I'd like to use the blessed JSON-RPC interface, but what's the recommended way to do that? What is (or will be!) the official recommended VDSM external client interface?
I thought about patch https://gerrit.ovirt.org/#/c/39203/
But my _impression_ is that patch will depend on VDSM's internal reactor, thus is not very suitable to be used into an external process.
I've written my own extremely crude client using the stomp library. Nir also has a patch [1] on gerrit to do this. Maybe he can provide some insight. It'd be nice if the vdsm-yajsonrpc package could provide a full-featured client class that could be easily integrated into projects like MOM.
I will try to provide simple client for people to use.
Thanks Piotr! I'm sure you can come up with a much more elegant way to stitch the existing classes together to do what we need. -- Adam Litke
On Thu, May 14, 2015 at 3:28 PM, Adam Litke <alitke@redhat.com> wrote:
On 13/05/15 22:53 +0200, Piotr Kliczewski wrote:
On Wed, May 13, 2015 at 9:52 PM, Adam Litke <alitke@redhat.com> wrote:
On 11/05/15 04:28 -0400, Francesco Romani wrote:
Hi everyone,
I'm working to brush up and enhance my old hack https://gerrit.ovirt.org/#/c/37827/1
That patch adds a new MOM interface, to talk with VDSM using the RPC interface. On top of that, I want to make efficient use of VDSM API (avoid redundant call, possibly issuing only one getAllVmStats call and caching the results, and so forth)
Next step will be to backport optimizations to current vdsmInterface. Or maybe, even replacing the new vdsminterface with the new one I'm developing :)
I'd like to use the blessed JSON-RPC interface, but what's the recommended way to do that? What is (or will be!) the official recommended VDSM external client interface?
I thought about patch https://gerrit.ovirt.org/#/c/39203/
But my _impression_ is that patch will depend on VDSM's internal reactor, thus is not very suitable to be used into an external process.
I've written my own extremely crude client using the stomp library. Nir also has a patch [1] on gerrit to do this. Maybe he can provide some insight. It'd be nice if the vdsm-yajsonrpc package could provide a full-featured client class that could be easily integrated into projects like MOM.
I will try to provide simple client for people to use.
Thanks Piotr! I'm sure you can come up with a much more elegant way to stitch the existing classes together to do what we need.
I posted a patch [1] with simplified way of building stomp client. It works in sync and async way. Can you please take a look and tell me whether it is OK or you want me to make more improvements. It is important to have it usable. [1] https://gerrit.ovirt.org/#/c/42850
-- Adam Litke
participants (4)
-
Adam Litke -
Dan Kenigsberg -
Francesco Romani -
Piotr Kliczewski