Re: [libvirt] libvirt-qpid
On Wed, 1 Oct 2008 11:10:41 +0100
"Daniel P. Berrange" <berrange(a)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-s...
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