qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [RFC v4 19/21] blockjobs: Expose manual pr


From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [RFC v4 19/21] blockjobs: Expose manual property
Date: Tue, 27 Feb 2018 15:42:09 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0


On 02/27/2018 03:16 PM, Eric Blake wrote:
> On 02/23/2018 05:51 PM, John Snow wrote:
>> Expose the "manual" property via QAPI for the backup-related jobs.
>> As of this commit, this allows the management API to request the
>> "concluded" and "dismiss" semantics for backup jobs.
>>
>> Signed-off-by: John Snow <address@hidden>
>> ---
>>   blockdev.c           | 19 ++++++++++++++++---
>>   qapi/block-core.json | 32 ++++++++++++++++++++++++++------
>>   2 files changed, 42 insertions(+), 9 deletions(-)
>>
> 
>> +++ b/qapi/block-core.json
>> @@ -1177,6 +1177,16 @@
>>   # @job-id: identifier for the newly-created block job. If
>>   #          omitted, the device name will be used. (Since 2.7)
>>   #
>> +# @manual: True to use an expanded, more explicit job control flow.
>> +#          Jobs may transition from a running state to a pending state,
>> +#          where they must be instructed to complete manually via
>> +#          block-job-finalize.
>> +#          Jobs belonging to a transaction must either all or all not
>> use this
>> +#          setting. Once a transaction reaches a pending state,
>> issuing the
>> +#          finalize command to any one job in the transaction is
>> sufficient
>> +#          to finalize the entire transaction.
> 
> The previous commit message talked about mixed-manual transactions, but
> this seems to imply it is not possible.  I'm fine if we don't support
> mixed-manual transactions, but wonder if it means any changes to the
> series.
> 
> Otherwise looks reasonable from the UI point of view.
> 

Refactor hell.

The intent (and my belief) is that as of right now you CAN mix them. In
earlier drafts, it was not always the case.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]