Re: [libvirt] libvirt-qpid
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.
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 :|