[libvirt] [PATCHv4 01/18] blockjob: add qemu capabilities related to block jobs

[Eric Blake]

On 04/10/2012 11:24 AM, Daniel P. Berrange wrote:

>>> As of this[1] qemu email, both commands have been proposed but not yet
>>> incorporated into the tree; in fact, the implementation I tested with
>>> has changed to match this[2] email that suggested a mandatory
>>> 'full':'bool' argument rather than 'mode':'no-backing-file'.  So there
>>> is a risk that qemu 1.1 will have yet another subtly different
>>> implementation.
>>> [1]https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01524.html
>>> [2]https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg00886.html
>>
>>
>> None of this gives me warm fuzzies :-/
> 
> Based on previous experience, my suggestion is that we do *not* merge
> any of this new libvirt API work, until the QEMU stuff has actually
> been accepted into their git master. The previous block streaming
> stuff is a nice history lesson in what happens when we merge stuff
> in libvirt before QEMU has agreed their final design :-(

I'll push hard on the qemu folks to at least commit to the qapi for qemu
1.1, even if the implementation is not available until after that point,
but I can live with the decision to not push the parts depending on the
new monitor commands.

This brings up some corollary questions:

patch 3/18 depends on the new monitor command only insofar as it uses
the existence of the command as a way to sanely tell if
'block_job_cancel' is asynchronous or synchronous.  I may be able to
rework that into something that doesn't depend on 'drive-mirror's
existence, by instead tracking whether an event has been issued; is it
worth me spending time on this effort, or should I wait for the qemu
reaction to committing to 'drive-mirror' first?

patch 2/18 and 4/18 are independent fixes, which could be pushed now
without waiting for 1/18.  Should I pursue this course of action?  It is
only in 1/18, as well as in 5/18 and later, where we are treading on the
dangerous ground of committing to a libvirt API without a reference
implementation in qemu; and even then, we can choose whether to commit
to the libvirt API without immediate qemu support.

All that said, I'd still appreciate a review of the full series, to
catch any other potential mistakes while the code is still fresh on my
mind, even if we delay pushing it to libvirt.git until qemu has made
more progress.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120410/95ffbd98/attachment-0001.sig>