Consumability of vdsm via libvdsm.so

Tue Aug 14 16:45:06 UTC 2012

On 08/14/2012 07:36 PM, Adam Litke wrote:
> On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi wrote:
>> I have an Idea, having json rpc for the over HTTP and 2 way json RPC over
>> openstacks' messaging abstraction layer.

Saggi, missed your idea for some reason -
+1 on your idea (following my comment to Adam regarding JNI and Java EE).

>
> So you are proposing to disregard all of the arguments in favor of a libvdsm and
> instead standardize on a protocol.  In that case, we could just keep xmlrpc...
> We will be back at square one having every application writing on object model
> on top of the transport.  We will also need to reinvent a model for ensuring
> backwards compatibility of the protocol data."

Adam,
When you use JNI, you generate java classes.
We can consider these classes as our "Java API" to the C library.
Why not have some dynamic proxy invoking this "Java API" in some IPC 
manner - there are plenty of frameworks to provide that.
We can use json as the format of the payload for the underlying 
transport (or some other format, XML, binary, etc..., this is just some 
"very high level design thought" I have).

>
>> This means we have 1 actual code base, the interfaces are on the transport
>> layer.  And if you choose to use messaging you (in the future) get 2 way
>> communication which means we can use.  Json-RPC notification for events. And
>> that we (in the future) might fit to an openstack cluster.
>
>> I still think generating the java bindings is preferable as it will have to be
>> done and having it generated straight from the schema is ideal.
>
> In that case we will also need to generate python bindings at a minimum.  In
> this model, how would REST and AMQP bridges be integrated?
>
>>
>> ----- Original Message -----
>>> From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron" <abaron at redhat.com> Cc:
>>> "Saggi Mizrahi" <smizrahi at redhat.com>, arch at ovirt.org Sent: Tuesday, August
>>> 14, 2012 10:09:28 AM Subject: Re: Consumability of vdsm via libvdsm.so
>>>
>>> On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam Litke"
>>>>>> <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday, August 13, 2012
>>>>>> 11:49:21 AM Subject: Re: Consumability of vdsm via libvdsm.so
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/13/2012 06:21 PM, Adam Litke wrote:
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We just finished a lively discussion regarding the ongoing effort to
>>>>>> stabilize the vdsm API using a C library called libvdsm.  There are
>>>>>> many things that need discussion, but I would like to focus this
>>>>>> thread on one in particular:
>>>>>>
>>>>>> Can ovirt-engine consume libvdsm via JNI?
>>>>>>
>>>>>> libvdsm provides a full-featured C interface to the vdsm API using
>>>>>> GObject.  Java bindings are provided automatically by jGIR[1].  The
>>>>>> library communicates with vdsmd using an internal transport which is
>>>>>> not exposed to end users (including ovirt-engine).  I would like to
>>>>>> learn from folks with deep Java knowledge if this approach is
>>>>>> workable.  What are the technical challenges to integrating in this
>>>>>> way?  Please save discussion of AMQP and other bindings for other
>>>>>> threads.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> [1] https://live.gnome.org/JGIR How mature/maintained is JGIR?  Last
>>>>>> commit seems to be 2010-02-09.  The author is: Alexander Kurtakov
>>>>>> <akurtako at redhat.com> His status in our organizational chart: Employee
>>>>>> Type: Ex-employee
>>>>> It will need some work to get it up to par with the rest of the gobject
>>>>> generators
>>>>
>>>> It's been dead since 2009, that doesn't seem very promising
>>>> (http://www.ohloh.net/p/java-gobject-introspection)
>>>>
>>>> It also states: "It also includes a custom GLib/GObject interface layer
>>>> adapted from gstreamer-java." and looking at gstreamer-java yields: "An
>>>> unofficial/alternative set of java bindings for the gstreamer multimedia
>>>> framework"
>>>>
>>>> Again, doesn't look like something you want to base your API on.  Sounds
>>>> to me like the 'free' java bindings come at a very high cost (bringing
>>>> JGIR up to date and maintaining it).
>>>>
>>>> What are the alternatives?
>>>
>>> There are two other alternatives (and one bad idea) that come to mind:
>>>
>>> 1.) Generate our own Java bindings to libvdsm.so during the vdsm build
>>> process.
>>>
>>> I prefer this option from an API cleanliness POV because the transport code
>>> would only be written once (in libvdsm.so).  This form of generation should
>>> be simple because we are just wrapping the library so it can be called via
>>> JNI.
>>>
>>>
>>> 2.) Generate a native Java "library" that is equivalent to libvdsm.so.
>>>
>>> This gets us into the business of libvirt-style bindings generation which I
>>> think is a mistake.  It opens the door to us maintaining parallel
>>> implementations of "libvdsm"s (one per language).
>>>
>>>
>>> -1.) Standardize the transport around JSON-RPC and make that the supported
>>> interface.
>>>
>>> I am only mentioning it because I am certain someone will bring it up.  I
>>> think it's a bad idea and it's off-topic for this particular thread anyway.
>>>
>>> -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
>>>
>>>
>>
>