Created attachment 419106 [details]
libvirt-list lists libvirt-qpid objects.
Description of problem:
I wrote a simple program to query libvirt-qpid some time ago. This program no longer works with latest release in RHEL6.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run qpidd, libvirt-qpid
2. Run libvirt-list.rb, note lack of return.
No objects are found.
libvirt-qpid objects should be found.
libvirt-list.rb is attached.
if you are using ruby to query libvirt-qpid, then yes. libvirt-qpid is working fine as of the last patch. However, the ruby qmf bindings are not working.
I think this should be high priority but will leave that up to tross.
This bug does not have any Target Milestone set.
Is that expected, Ian? This way it will be forgotten soon.
Please set it if you want this bug to be resolved. Thanks.
OK, I'm setting this to high in the hopes it will be looked at. :)
Well I'd like to see this fixed for rhel6 but am not sure what target milestone should be set to. I set it to 'next version' for now?
Ted, are you working on this for 1.3? This bug prevents me from
running the stress test written by M. Morsi - see branch
jasan at http://ooo.englab.brq.redhat.com/c/movitto-qmf.git/
which contains current changes that make at least the C++ part
work (methods tested with qpid-tool). But the ruby console does
not see the C++ agent so I can not use the test as it is.
It worked previously.
Is this still a valid mrg-blocker after today's explanation by Ted that this
is reversed only for RHEL6 so that libvirt-qmf works there?
This is the WAY FORWARD(tm). These bindings are how the python bindings should be done along side the ruby bindings. This should definitely be a blocker. This should never have gotten as far behind as it is IMO.
What's the status here, please?
Is this going into 2.0? What's the progress?
I'm nacking this BZ... A new Ruby API has been introduced for QMFv2 which does not have the same problem as the existing Ruby API. There are two possibilities for moving forward:
1) Migrate the test tools to the new API (preferred)
2) Provide old-API support for QMFv2 (I'm not sure there's value in doing this)