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" <agl(a)us.ibm.com>
> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> Cc: "Anthony Liguori" <anthony(a)codemonkey.ws>, "VDSM Project
Development" <vdsm-devel(a)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" <agl(a)us.ibm.com>
> > > To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> > > Cc: "Anthony Liguori" <anthony(a)codemonkey.ws>, "VDSM
Project
> > > Development" <vdsm-devel(a)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 <agl(a)us.ibm.com>
> IBM Linux Technology Center
>
>
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center