[libvirt] libvirt-qpid

[Daniel P. Berrange]

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.

> 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.

> - Need rc scripts, daemonization, better reconnect/error handling for
> both qpid and libvirt.  I think it should attempt to reconnect until
> successful whenever it gets disconnected.  We may need an extra status
> property for this state as well.

You can probably just copy the libvirtd init script & rename the daemon
process in it - particularly if you follow the libvirtd argv parsing.

Auto-reconnecting upon failure is a interesting idea - be good to
be able to restart libvirtd, without needing to bounce the agent
too

> - Return libvirt error codes? (it's just text msgs right now with error
>   status bit).

Yep, we need to include as much of the libvirt error object data as
possible - merely skip the 'domain' and 'network' deprecated fields,
and the 'connect' field which is irrelevant iun this context.

> - Make it less chatty, but log stuff

Configurable use of syslog() would be a good idea. For sake of consistency
I'd recommend looking at the libvirtd daemon, and its command line arg
handling - see  qemud/qemud.c file and the main() method in it.  Pretty
much all the libvirtd  argv would make sense for libvirt-qpid agent.

> If you wish to try it out, I've made rpms for fedora 9 x86_64 and i386.
> They are in the ovirt repo, which you can add to yum using:
> 
> rpm -ivh http://ovirt.org/repos/ovirt/9/ovirt-release-LATEST.fc9.noarch.rpm
> 
> Once you have that set up, 'yum install libvirt-qpid python-qpid', and then
> run (each in their own terminals):
> 
> qpidd --auth no
> libvirt-qpid (as root to auth with libvirt)
> qpid-tool

Have you tried it out across with a network of machines all routing
over a AMQP grid ? I'm interested to know how 'chatty' it is as we
add lots of libvirt nodes - particularly wrt to the pushing of domain
statistics on a frequent basis for lots of domains.

> 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.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|