All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-block@nongnu.org,  qemu-devel@nongnu.org,
	 hreitz@redhat.com, kwolf@redhat.com,  eblake@redhat.com,
	 jsnow@redhat.com, devel@lists.libvirt.org,  pkrempa@redhat.com,
	 michael.roth@amd.com, pbonzini@redhat.com
Subject: Re: [PATCH] [for-10.1] qapi/block-core: derpecate some block-job- APIs
Date: Fri, 04 Apr 2025 16:13:15 +0200	[thread overview]
Message-ID: <87ecy8nhfo.fsf@pond.sub.org> (raw)
In-Reply-To: <638e4d21-6440-47e7-9ad5-ac44b0c03cb0@yandex-team.ru> (Vladimir Sementsov-Ogievskiy's message of "Fri, 4 Apr 2025 14:33:37 +0300")

Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:

> On 04.04.25 09:20, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:

[...]

>>> +
>>> +``block-job-finalize`` (since 10.1)
>>> +''''''''''''''''''''''''''''''''''
>>> +
>>> +Use ``job-finalize`` instead.
>>> +
>> 
>> block-job-finalize's doc comment:
>> 
>>      # Once a job that has manual=true reaches the pending state, it can be
>>      # instructed to finalize any graph changes and do any necessary
>>      # cleanup via this command.  [...]
>> 
>> There is no member @manual anywhere in the QAPI schema.  I figure this
>> should be @auto-finalize.
>> 
>> job-finalize's doc comment:
>> 
>>      # Instructs all jobs in a transaction (or a single job if it is not
>>      # part of any transaction) to finalize any graph changes and do any
>>      # necessary cleanup.  This command requires that all involved jobs are
>>      # in the PENDING state.
>> 
>> Nothing on @auto-finalize.
>> 
>> @auto-finalize defaults to true for jobs that support controlling it.
>> These are exactly the ones that support @auto-dismiss.
>> 
>> I figure @auto-dismiss is always false for the other jobs, but that
>> doesn't seem to be documented anywhere.
>> 
>> The only other bits related to @auto-dismiss and @auto-finalize seem to
>> be two states in JobStatus:
>> 
>>      # @pending: The job has finished its work, but has finalization steps
>>      #     that it needs to make prior to completing.  These changes will
>>      #     require manual intervention via @job-finalize if auto-finalize
>>      #     was set to false.  These pending changes may still fail.
>>      [...]
>>      # @concluded: The job has finished all work.  If auto-dismiss was set
>>      #     to false, the job will remain in the query list until it is
>>      #     dismissed via @job-dismiss.
>> 
>> 
>> Is it possible to observe @concluded via QMP when @auto-dismiss is on?
>
> Seems not.
>
>> 
>> What about @pending?
>
> Hmm probably, if we have a transaction of several jobs (actually only backups may be joined to transactions), where some have auto-finalize and some not, the whole transaction would be pending, including jobs that has auto-finalize=true. Still, it's a strange case.

So, auto-finalize=true is silently ignored when another job in the same
transaction has auto-finalize=false?

>> Aside: getting rid of auto-dismiss and auto-finalize some day would be
>> nice.
>> 
>
> Hmm.. You mean, deprecated "true" value, and finally drop the fields, making "false" the default? May be.

May or may not be practical.

> I'll resend, with additional patch to touch-up the documentation.

Thanks!



  reply	other threads:[~2025-04-04 14:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01 15:57 [PATCH] [for-10.1] qapi/block-core: derpecate some block-job- APIs Vladimir Sementsov-Ogievskiy
2025-04-01 16:32 ` Peter Krempa
2025-04-04  6:20 ` Markus Armbruster
2025-04-04 11:33   ` Vladimir Sementsov-Ogievskiy
2025-04-04 14:13     ` Markus Armbruster [this message]
2025-04-04 15:03       ` Vladimir Sementsov-Ogievskiy
2025-04-05  7:13         ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ecy8nhfo.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=devel@lists.libvirt.org \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@yandex-team.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.