Re: [Qemu-block] [Qemu-devel] [PATCH v2 02/11] blockjob: centralize QMP event emissions

[Eric Blake]

On 10/10/2016 01:36 PM, John Snow wrote:
>>>>  But if it cannot figure out which upper-layer disk the event is
>>>> associated with, it just drops the event.  So I think that from the
>>>> libvirt perspective, you are okay if if you always report job events,
>>>> even for internal jobs.  (Do we have a quick and easy way to set up an
>>>> internal job event, to double-check if I can produce some sort of
>>>> libvirt scenario to trigger the event and see that it gets safely
>>>> ignored?)
>>>>
>>>
>>> Not in a QEMU release yet, I think.
>>
>> If not from an official QEMU release, it'd still be useful to work out a
>> a way to reproduce what Eric asked even from upstream Git master.
>>
> 
> I'll be honest that I don't know; this is related to Replication which I
> know reasonably little about overall. It got added in the 2.8 timeframe,
> so the behavior it currently exhibits is not a good or meaningful
> reference for maintaining compatibility.
> 
> We can /change/ the behavior before releases with no love lost.

And if Replication is the only way to trigger internal use of jobs, then
we aren't breaking libvirt (which doesn't know how to drive replication
yet) by changing anything on that front.

> 
> Or, what if you just didn't get events for internal jobs? Are events for
> un-managed jobs useful in any sense beyond understanding the stateful
> availability of the drive to participate in a new job?

If libvirt isn't driving replication, then it's a moot point. And even
though replication in libvirt is not supported yet, I suspect that down
the road when support is added, the easiest thing for libvirt will be to
state that replication and libvirt-controlled block jobs are mutually
exclusive; there's probably enough lurking dragons that if your system
MUST be high-reliance by replication, you probably don't want to be
confusing things by changing the backing file depth manually with
streams, pulls, or other manual actions at the same time as replication
is managing the system, because how can you guarantee that both primary
and secondary see the same manual actions at all the right times?

At any rate, not seeing internal-only jobs is probably the most
reasonable, even if it means an internal-only job can block the attempt
to do a manual job.

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

signature.asc
Description: OpenPGP digital signature