[niftyname-users] XML/RPC vs libvirt?

Bertrand Yvain pnl at ielo.net
Tue Mar 31 17:17:37 CEST 2009


Thanks for your interest in the project,

On Tue, Mar 31, 2009 at 02:27:47PM +0000, Yann Hamon wrote:
> Is there any plan to support libvirt on top of or in replacement of the
> XML/RPC interface - and what is the reason you went for an XML/RPC
> interface, missing features in libvirt?

The XML-RPC interface in SINN/ZINN serves a different purpose than
libvirt.  Unless I'm mistaken, libvirt's range of operation is bound to a
single node.  SINN is focused on multi-node setups (you might even have
trouble to run the suite on a single host).  libvirt compares more to the
hostmgrd of the SINN suite.

We, at IELO/Lost-Oasis, began to use libvirt when we launched our first
commercial virtual server solution, more than one year ago, but we've
backed up on that.  The main issue we had with libvirtd is that it can
only control child processes.  This means that if libvirtd dies for any
reason, your guests become unmanageable.  We felt that it was a very poor
design choice in term of resilience.  Besides, there is currently no plan
to support any other virtualization solution besides KVM.  Dropping
libvirt made the code much simpler and the service more stable.

However, there is no definite choice upon XML-RPC.  I would very much like
to see new protocols implemented as alternatives to XML-RPC.  SNMP would
probably be on the top of my list.  We could also imagine a RESTful API
over HTTP.  Both could really reduce the stress on management nodes in
very large deployements.

> Also, the released is tagged 1.0 - does this means that it is production
> ready, and has already been subject to a wide range of beta
> testing/deployments?

v1.0.0 is not production ready, unless you're prepared to sacrifice a lot
of sleep.  As a matter of fact, here is the tag comment in git:

Release as 1.0.0.  Still experimental.

We had quite of a discussion about version numbering and there are a few
elements that made us go for v1 at this point:

- This is a turning point for the project that really goes public and is
  ready to accept contributors with a decent codebase.  Mostly
  psychological, indeed :)

- Current functionnality is sufficient to run on a single site.  We need
  to attract testers for this part while the effort goes on with features
  like mulitsite redundance and dynamic ressource allocation.


Cheers,
-- 
Bertrand Yvain


More information about the niftyname-users mailing list