[libvirt] libvirt-qpid

[Ian Main]

On Wed, 1 Oct 2008 11:10:41 +0100
"Daniel P. Berrange" <berrange at redhat.com> wrote:

> On Wed, Sep 24, 2008 at 10:55:36AM -0700, Ian Main wrote:
> > 
> > So I've been working on a qpid interface to libvirt.  Here's the description
> > I've come up with:
> > 
> > libvirt-qpid provides an interface with libvirt using QMF (qpid modeling
> > framework) which utilizes the AMQP protocol.  The Advanced Message Queuing
> > Protocol (AMQP) is an open standard application layer protocol providing
> > reliable transport of messages.
> > 
> > QMF provides a modeling framework layer on top of qpid.  This interface 
> > allows you to manage hosts, domains, pools etc. as a set of objects with 
> > properties and methods.
> > 
> > The source code repo:
> > 
> > http://git.et.redhat.com/?p=libvirt-qpid.git;a=summary
> > 
> > So I'd like to hear any feedback you guys might have.  This file in particular
> > describes the API that is used to interact with libvirt.
> > 
> > http://git.et.redhat.com/?p=libvirt-qpid.git;a=blob_plain;f=src/libvirt-schema.xml
> 
> I really like how you decided to go for a 1-to-1 mapping of libvirt C
> API into QMF api :-) 
> 
> I am still kinda undecided about the Node vs Connect root object, but
> I'm leaning towards your current model, or 1 libvirt-qpid agent using
> a specific libvirt connect URI, thus making an explicit Connect object
> unneccessary. If someone wants to export multiple hypervisor connections
> that it ought to be possible to run multiple instances of the daemon
> 
> Also, if we want to have a real accurate 1-to-1 mapping, then really
> the Domain statistics would be better in a DomainInfo object, in the
> same way you've dealt with Node, vs NodeInfo objects.

Hmm.. I guess I just wonder why you would separate them.  From a 'look at
the objects' point of view they may as well just be in the class.  But then
I'm guessing that would be more for compatibility.

Actually, another way to look at it is that it is really just a bunch of info
about a domain that is returned in a structure rather than a single call like
many of the other properties already in the domain. :)

hehe, if it's a big deal I can change it :).

> > My TODO list looks like this:
> > 
> > - Not sure on camel case or underscores.  Original libvirt API uses
> > camel case, I went with underscores as I was originally basing it off
> > the ruby bindings.
> 
> Typically this is decided according to conventions of the language
> being bound to. Are there any established conventions by people doing
> QMF work ? If there are none, then I'd recommend we stick to the 
> convention used by the libvirt C  library.

It sounds like we're going camel.  qmf uses camelcase too.

Sounds like for the rest we're in agreement.  Just some time to implement
is needed. :)

> > qpid-tool provides an interface to qpid and allows you to view/manipulate the
> > qpid models/objects.  Here is an example of how it looks using qpid-tool:
> 
> This is perhaps the bit I like most about QPID - automatically
> get a single point global view of the system, with a reliable
> messaging backbone, and strong authentication & strong typing.

Yeah it's pretty neat.

	Ian