Re: [libvirt] libvirt-qpid

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.