Re: [Qemu-devel] [PATCH v5 00/21] blockjobs: add explicit job management

[Markus Armbruster]

John Snow <address@hidden> writes:

> This series seeks to address two distinct but closely related issues
> concerning the job management API.
>
> (1) For jobs that complete when a monitor is not attached and receiving
>     events or notifications, there's no way to discern the job's final
>     return code. Jobs must remain in the query list until dismissed
>     for reliable management.
>
> (2) Jobs that change the block graph structure at an indeterminate point
>     after the job starts compete with the management layer that relies
>     on that graph structure to issue meaningful commands.
>
>     This structure should change only at the behest of the management
>     API, and not asynchronously at unknown points in time. Before a job
>     issues such changes, it must rely on explicit and synchronous
>     confirmation from the management API.
>
> These changes are implemented by formalizing a State Transition Machine
> for the BlockJob subsystem.
>
> Job States:
>
> UNDEFINED       Default state. Internal state only.
> CREATED         Job has been created
> RUNNING         Job has been started and is running
> PAUSED          Job is not ready and has been paused
> READY           Job is ready and is running
> STANDBY         Job is ready and is paused
>
> WAITING         Job is waiting on peers in transaction
> PENDING         Job is waiting on ACK from QMP
> ABORTING        Job is aborting or has been cancelled
> CONCLUDED       Job has finished and has a retcode available
> NULL            Job is being dismantled. Internal state only.
>
> Job Verbs:
>
> CANCEL          Instructs a running job to terminate with error,
>                 (Except when that job is READY, which produces no error.)
> PAUSE           Request a job to pause.
> RESUME          Request a job to resume from a pause.
> SET-SPEED       Change the speed limiting parameter of a job.
> COMPLETE        Ask a READY job to finish and exit.
>
> FINALIZE        Ask a PENDING job to perform its graph finalization.
> DISMISS         Finish cleaning up an empty job.

For each job verb and job state: what's the new job state?

> And here's my stab at a diagram:
>
>                  +---------+
>                  |UNDEFINED|
>                  +--+------+
>                     |
>                  +--v----+
>        +---------+CREATED+-----------------+
>        |         +--+----+                 |
>        |            |                      |
>        |         +--+----+     +------+    |
>        +---------+RUNNING<----->PAUSED|    |
>        |         +--+-+--+     +------+    |
>        |            | |                    |
>        |            | +------------------+ |
>        |            |                    | |
>        |         +--v--+       +-------+ | |
>        +---------+READY<------->STANDBY| | |
>        |         +--+--+       +-------+ | |
>        |            |                    | |
>        |         +--v----+               | |
>        +---------+WAITING+---------------+ |
>        |         +--+----+                 |
>        |            |                      |
>        |         +--v----+                 |
>        +---------+PENDING|                 |
>        |         +--+----+                 |
>        |            |                      |
>     +--v-----+   +--v------+               |
>     |ABORTING+--->CONCLUDED|               |
>     +--------+   +--+------+               |
>                     |                      |
>                  +--v-+                    |
>                  |NULL+--------------------+
>                  +----+

Is this diagram missing a few arrowheads?  E.g. on the edge between
RUNNING and WAITING.

Might push the limits of ASCII art, but here goes anyway: can we label
the arrows with job verbs?

Can you briefly explain how this state machine addresses (1) and (2)?