[libvirt] libvirt-qpid

[Daniel Veillard]

On Thu, Oct 02, 2008 at 03:40:06PM +0100, Daniel P. Berrange wrote:
> On Thu, Oct 02, 2008 at 03:06:01PM +0200, Daniel Veillard wrote:
> >   You also need 'yum install qpidd' I suspect this indicates a missing
> > dependancy maybe in the libvirt-qpid package but I'm not 100% sure
> 
> Yeah, i believe that should be a requirement. NB, the versions of qpidc
> and qpidd in Fedora currently are too old for libvirt-qpid. I've been 
> speaking with qpid maintainer and they'll push a new build to Fedora in
> the very near future.

  Ah, that probably explains why that didn't work for me, I got my qpidd
from Fedora ...
  Another question, upon rebout the QPid service starts automatically,
I wonder if there is something to do to be able to connect assuming
a "default install" and not starting without auth .

> > BTW i would suggest to rename qpid-tool to libvirt-qpid-tool or
> > virt-qpid-tool to avoid confusion about the scope.
> 
> Actually qpid-tool is a general purpose shell  provided by qpid
> themselves, not a libvirt specific thing - if you have other
> agents active it'll show those objects as wel as the libvirt
> ones.

  Oops my bad, i didn't realize it came from qpid itself, good to know.

> > 
> > Some comments about the XML schemas:
> >  - camelCaseDanke :-)
> >  - Node has methods domain_define_xml, storage_pool_define_xml and
> >    storage_pool_create_xml
> >    I think at least for symetry domain_create_xml should be available
> >    there too.
> 
> Yep, all APIs should be expressed in the qpid binding eventually.
> 
> >  - I would make an Error class mimicking at least partially what's
> >    available in libvirt C or python bindings
> >  - Domain.create() is very confusing, again I would define domain
> >    creation under node, i.e. temporary 'undefined' domains. Then
> >    <method name="create" desc="Start stopped VM"/>
> >    should probably be renamed 'start' to avoid confusion.
> >    and the comment "Start a defined but stopped domain" would be more
> >    adequate by mentioning the define API...
> 
> The trouble with that is it would diverge from libvirt naming - admittedly
> the libvirt naming isn't ideal, but i figure consistency is better so 
> people can cross-reference API documentation more easily. So the 'create'
> method on Domain does make sense,

  okay but let's improve the comment then, it's really confusing

> but we'd expect another 'createLinux'
> method on the Node object for unmanaged domains - though it might be
> worth breaking with consistency in this one case and dropping the 'Linux'
> suffix from the name there .

  Yeah, the Linux suffix is a remain from the very early days with
paravirt. Actually we should fix libvirt itself and just provide the
old symbol for compatibility.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/