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/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
