[ovirt-devel] [vdsm][mom][jsonrpc] new VDSM interface for MOM

[Francesco Romani]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Francesco Romani" <fromani at redhat.com>, alitke at redhat.com, ykaplan at redhat.com
> Cc: devel at 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