On 2012-7-12 20:41, Adam Litke wrote:
On Thu, Jul 12, 2012 at 08:11:17AM +0800, Shu Ming wrote:
Basically,  my understanding is that we can generate two versions of
libvdsm from the schema file for both the node and the management
application.  First, the transportation protocols(XMLRPC, REST-API)
will depend on libvdsm(node version) to export the APIs to remote
management application.  Secondly, the management application can
use libvdsm(application version ) to emit the remote call to the
node.   Also, transportation protocols like REST API and XML RPC API
can also be generated automatically by the schema file with C, Java,
Python bindings.
I think this might be a bit too complex of a model.  Here's how I see it...

The schema generates C/gObject code which can be compiled into libvdsm.  We can
use the gObject introspection library to automatically generate language
bindings for Java, Python, Perl, etc.
Do you mean Java, Python, Perl, etc bindings of libvdsm?

The libvdsm library talks to vdsmd using a wire protocol that works locally and
remotely.  This wire protocol is completely hidden from library users.  It's an
implementation detail that can be changed later if necessary.  Today I would
recommend that we use xmlrpc.  This means that ovirt-engine or another remote
program could use libvdsm in the exact same manner as a local program.  The
library user just needs to call libvdsm.connect(uri).

Except libvdsm.connet() or libvdsm.disconnet(), do you expect the engine will not change any of its xml-rpc interfaces now after libvdsm is introduced? I mean engine may not want to change much of its current code, so it expect the least change.

Finally, REST and AMQP bridges would be written solely against libvdsm.  These

So we should write REST, AMQP bridges manually with Java, Python, Perl language on various bindings of libvdsm?

bridges are probably not suitable for code generation (but we can revisit that
as a separate issue because it's up to the bridge writer to determine the best

On 2012-7-12 2:29, Saggi Mizrahi wrote:
I'm sorry, but I don't really understand the drawing

----- Original Message -----
From: "Shu Ming" <shum...@linux.vnet.ibm.com>
To: "Adam Litke" <a...@us.ibm.com>
Cc: vdsm-devel@lists.fedorahosted.org
Sent: Wednesday, July 11, 2012 10:24:49 AM
Subject: Re: [vdsm] [RFC] An alternative way to provide a supported interface 
-- libvdsm


Maybe,  I don't fully understand your proposal.  Here is my
understanding of libvdsm in the picture. Please check the following
for the picture.



On 2012-7-9 21:56, Adam Litke wrote:
On Fri, Jul 06, 2012 at 03:53:08PM +0300, Itamar Heim wrote:
On 07/06/2012 01:15 AM, Robert Middleswarth wrote:
On 07/05/2012 04:45 PM, Adam Litke wrote:
On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote:
----- Original Message -----
From: "Adam Litke" <a...@us.ibm.com>
To: "Saggi Mizrahi" <smizr...@redhat.com>
Cc: "Anthony Liguori" <anth...@codemonkey.ws>, "VDSM Project
Development" <vdsm-devel@lists.fedorahosted.org>
Sent: Thursday, July 5, 2012 2:34:50 PM
Subject: Re: [RFC] An alternative way to provide a supported
interface -- libvdsm

On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote:
The idea of having a supported C API was something I was
about doing
(But I'd rather use gobject introspection and not schema
generation) But the
problem is not having a C API is using the current XML RPC
API as
it's base
I want to disect this a bit to find out exactly where there
might be
and disagreement.

C API is a good thing to implement - Agreed.

I also want to use gobject introspection but I don't agree
that using
precludes the use of a formalized schema.  My proposal is that
write a schema
definition and generate the glib C code from that schema.

I agree that the _current_ xmlrpc API makes a pretty bad base
which to
start a supportable API.  XMLRPC is a perfectly reasonable
remote/wire protocol
and I think we should continue using it as a base for the next
generation API.
Using a schema will ensure that the new API is
There major problems with XML-RPC (and to some extent with REST
well) are high call overhead and no two way communication (push
events). Basing on XML-RPC means that we will never be able to
these issues.
I am not sure I am ready to conceed that XML-RPC is too slow for
needs.  Can
you provide some more detail around this point and possibly
suggest an
alternative that has even lower overhead without sacrificing the
ubiquity and
usability of XML-RPC?  As far as the two-way communication
point, what
are the
options besides AMQP/ZeroMQ?  Aren't these even worse from an
perspective than XML-RPC?  Regarding two-way communication: you
write AMQP
brokers based on the C API and run one on each vdsm host.
the C API
supports events, what else would you need?
I personally think that using something like AMQP for inter-node
communication and engine - node would be optimal.  With a rest
that just send messages though something like AMQP.
I would also not dismiss AMQP so soon
we want a bug with more than a single listener at engine side
(engine, history db, maybe event correlation service).
collectd as a means for statistics already supports it as well.
I'm for having REST as well, but not sure as main one for a
like ovirt engine.
I agree that a message bus could be a very useful model of
communication between
ovirt-engine components and multiple vdsm instances.  But the
complexities and
dependencies of AMQP do not make it suitable for use as a low-level
will repel new adopters.  Why not establish a libvdsm that is more
and can be easily used by everyone?  Then AMQP brokers can be built
on top of
the stable API with ease.  All AMQP should require of the low-level
API are
standard function calls and an events mechanism.

The current XML-RPC API contains a lot of decencies and
inefficiencies and we
would like to retire it as soon as we possibly can. Engine
like us to
move to a message based API and 3rd parties want something
like REST so
it looks like no one actually wants to use XML-RPC. Not even
I am proposing that AMQP brokers and REST APIs could be
against the
public API.  In fact, they need not even live in the vdsm tree
anymore if that
is what we choose.  Core vdsm would only be responsible for
and whatever language bindings we want to support.
If we take the libvdsm route, the only reason to even have a
bridge is only to support OSes other then Linux which is
I'm not sure we care about at the moment.
That might be true regarding the current in-tree implementation.
However, I can
almost guarantee that someone wanting to write a web GUI on top
vdsm would want a REST API to talk to.  But libvdsm makes this
case of no
concern to the core vdsm developers.

I do think that having C supportability in our API is a good
but the
current API should not be used as the base.
Let's _start_ with a schema document that describes today's
API and
then clean
it up.  I think that will work better than starting from
   Once my
schema is written I will post it and we can 'patch' it as a
until we
arrive at a 1.0 version we are all happy with.
Ok.  Redoubling my efforts to get this done.  Describing the
output of
list(True) takes awhile :)

vdsm-devel mailing list
vdsm-devel mailing list
Shu Ming <shum...@linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory

vdsm-devel mailing list

Shu Ming <shum...@linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory

Shu Ming <shum...@linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory

vdsm-devel mailing list

Reply via email to