Adding danpb and DV to get some perspective from libvirt...

On Thu, Jul 05, 2012 at 05:02:59PM -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 4:45:08 PM
> > Subject: Re: [RFC] An alternative way to provide a supported interface -- 
> > libvdsm
> > 
> > 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
> > > > > thinking
> > > > > 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
> > > > agreement
> > > > 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
> > > > glib
> > > > precludes the use of a formalized schema.  My proposal is that we
> > > > 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
> > > > from
> > > > 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 well-structured.
> > > There major problems with XML-RPC (and to some extent with REST as
> > > well) are high call overhead and no two way communication (push
> > > events). Basing on XML-RPC means that we will never be able to
> > > solve these issues.
> > 
> > I am not sure I am ready to conceed that XML-RPC is too slow for our
> > 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
> > overhead
> > perspective than XML-RPC?  Regarding two-way communication: you can
> > write AMQP
> > brokers based on the C API and run one on each vdsm host.  Assuming
> > the C API
> > supports events, what else would you need?
> If we plan to go with the libvdsm route the only transports I think are 
> appropriate are either raw sockets (like libvirt) or ZMQ (just to take 
> advantage of it managing connection and message encapsulation but it might be 
> an overkill). Other then that ZMQ\AMQP\REST\XML-RPC bridges are not really a 
> priority for me as engine will not be using any of the bridges.

I think (and others have also suggested) that ZMQ is not very suitable as the
foundation of an API due to it's heavy weight.  I would really appreciate the
perspective of the libvirt guys and others in the community on this topic.
Between you and I, the only approach that hasn't been nacked is:
raw sockets and xdr ala libvirt.  Are there any detractors of this idea?
Anything better to consider?  xdr is ancient :)

> > 
> > > > > 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
> > > > > would
> > > > > like us to
> > > > > move to a message based API and 3rd parties want something
> > > > > simple
> > > > > like REST so
> > > > > it looks like no one actually wants to use XML-RPC. Not even
> > > > > us.
> > > > 
> > > > I am proposing that AMQP brokers and REST APIs could be written
> > > > 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
> > > > providing
> > > > libvdsm
> > > > and whatever language bindings we want to support.
> > > If we take the libvdsm route, the only reason to even have a REST
> > > bridge is only to support OSes other then Linux which is something
> > > 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 of
> > standalone
> > vdsm would want a REST API to talk to.  But libvdsm makes this use
> > case of no
> > concern to the core vdsm developers.
> > 
> > > > > I do think that having C supportability in our API is a good
> > > > > idea,
> > > > > 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 scratch.
> > > >  Once my
> > > > schema is written I will post it and we can 'patch' it as a
> > > > community
> > > > until we
> > > > arrive at a 1.0 version we are all happy with.
> > > +1
> > 
> > Ok.  Redoubling my efforts to get this done.  Describing the output
> > of
> > list(True) takes awhile :)
> > 
> > --
> > Adam Litke <a...@us.ibm.com>
> > IBM Linux Technology Center
> > 
> > 
> 

-- 
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to