On Fri, Jul 06, 2012 at 01:30:43PM +0100, Daniel P. Berrange wrote:
On Fri, Jul 06, 2012 at 07:17:44AM -0500, Adam Litke wrote:
> Adding danpb and DV to get some perspective from libvirt...
>
> On Thu, Jul 05, 2012 at 05:02:59PM -0400, Saggi Mizrahi wrote:
> >
> > >
> > > 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 :)
I think I've already given my views on this earlier in the thread.
To recap, I think that it is very important for the core functionality
of VDSM to be easy to get up & running / deployment. Adding a serious
messaging layer like AMQP or similar, as a mandatory component puts a
non-negligable barrier to entry.
Probably one of the most important things that drove adoption of libvirt
was that you can use it remotely & securely with no external infrastructure.
You just start libvirtd & can access it via its SSH tunnel facility. Of
course for most production deployments you wouldn't use this, but it is
important for encouraging developers to work on it & making it easy for
users to just try it out on a small scale.
WRT to XDR, remember that it is not a protocol - it is simply a spec for
how to encode various data structures in an efficient binary format. I
don't think how old it is really relevant, since there's only so many
different ways you want to encode binary data structures.
Since it is just a data format encoding, you have the job of defining
the actual RPC protocol on top of that. Now this isn't particularly
hard to get going at first, but the complexity does add up over time.
I'd still suggest aiming for some variant of REST for its simplicity
and the fact that you can then use standard HTTP server & client
components and solely focus on your APIs, rather than infrastructure.
As Dan said xdr as the encoder is fine, but won't provide a protocol.
If you go that way this also mean that everybody will have to use the
library stub to talk to your server API, point in case nobody ever used
the API at the RPC level to talk to libvirtd (though we work very hard
to keep that ABI stable too).
I guess that in a situation like talking to vdsm you don't want to
force people to go though a library you have to maintain/control/distribute
which is why I would suggest too to avoid the mess and export with a
common and easy to use protocol. My experience is that if you want an
API to be used you have to make it as easy to use as possible to get
traction (especially when you are competing with other solutions), and
forcing to go through a given library should be avoided if you can.
Having to maintain a zillion bindings (having spend just way to much
time lately with libvirt-java) takes time that could be invested better
on the core functionalities by just using a remote protocol available
in a variety of language.
IMHO speed of encoding/decoding is pure noise. HTTP should be a proof
that you can design a slow solution and have it take over the world just
because it's easier to implement, use and debug. Pick an ubiquitous
solution or be ready to spend an awful lot of time maintainaing client
side entry points, bindings, distribution, work around protocol problems
etc...
my 2 cents,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/