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.

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
vdsm-devel mailing list

Reply via email to