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

[Markus Armbruster]

John Snow  writes:

> On 04/18/2018 03:25 AM, Markus Armbruster wrote:
>> John Snow  writes:
>> 
>>> On 04/17/2018 09:44 AM, Markus Armbruster wrote:
 John Snow  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
> ABORTINGJob is aborting or has been cancelled
> CONCLUDED   Job has finished and has a retcode available
> NULLJob is being dismantled. Internal state only.
>
> Job Verbs:
>
>>>
>>> Backporting your quote up here:
>>>
 For each job verb and job state: what's the new job state?

>>>
>>> That's not always 1:1, though I tried to address it in the commit messages.
>> 
>> Let me rephrase my question then.  For each job verb and job state: what
>> are the possible new job states?  If there's more than one, what's the
>> condition for each?
>> 
>
> Is my answer below not sufficient? Maybe you're asking "Can you write
> this up in a formal document" instead, or did I miss explaining something?

Your answer was fine.  I blame my one-pass reply writing.

Nevertheless:

>> I appreciate commit messages explaining that, but having complete state
>> machine documentation in one place (a comment or in docs/) would be
>> nice, wouldn't it?

Pretty-please?

> CANCEL  Instructs a running job to terminate with error,
> (Except when that job is READY, which produces no error.)
>>>
>>> CANCEL will take a job to either NULL... (this is the early abort
>>> pathway, prior to the job being fully realized.)
>>>
>>> ...or to ABORTING (from CREATED once it has fully realized the job, or
>>> from RUNNING, READY, WAITING, or PENDING.)
>>>
> PAUSE   Request a job to pause.
>>>
>>> issued to RUNNING or READY, transitions to PAUSED or STANDBY respectively.
>>>
> RESUME  Request a job to resume from a pause.
>>>
>>> issued to PAUSED or STANDBY, transitions to RUNNING or READY respectively.
>>>
> SET-SPEED   Change the speed limiting parameter of a job.
>>>
>>> No run state change.
>>>
> COMPLETEAsk a READY job to finish and exit.
>
>>>
>>> Issued to a READY job, transitions to WAITING.
>>>
> FINALIZEAsk a PENDING job to perform its graph finalization.
>>>
>>> Issued to a PENDING job, transitions to CONCLUDED.
>>>
> DISMISS Finish cleaning up an empty job.

>>>
>>> Issued to a CONCLUDED job, transitions to NULL.
>>>
>>>
> And here's my stab at a diagram:
>
>  +-+
>  |UNDEFINED|
>  +--+--+
> |
>  +--v+
>+-+CREATED+-+
>| +--++ |
>||  |
>| +--++ +--+|
>+-+RUNNING<->PAUSED||
>| +--+-+--+ +--+|
>|| ||
>|| +--+ |
>||| |
>| +--v--+   +---+ | |
>+-+READY<--->STANDBY| | |
>| +--+--+   +---+ | |
>||| |
>| +--v+   | |
>+-+WAITING<---+ |
>| +--++ |
>||  |
>| 

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

[John Snow]

On 04/18/2018 03:25 AM, Markus Armbruster wrote:
> John Snow  writes:
> 
>> On 04/17/2018 09:44 AM, Markus Armbruster wrote:
>>> John Snow  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
 ABORTINGJob is aborting or has been cancelled
 CONCLUDED   Job has finished and has a retcode available
 NULLJob is being dismantled. Internal state only.

 Job Verbs:

>>
>> Backporting your quote up here:
>>
>>> For each job verb and job state: what's the new job state?
>>>
>>
>> That's not always 1:1, though I tried to address it in the commit messages.
> 
> Let me rephrase my question then.  For each job verb and job state: what
> are the possible new job states?  If there's more than one, what's the
> condition for each?
> 

Is my answer below not sufficient? Maybe you're asking "Can you write
this up in a formal document" instead, or did I miss explaining something?

> I appreciate commit messages explaining that, but having complete state
> machine documentation in one place (a comment or in docs/) would be
> nice, wouldn't it?
> 
 CANCEL  Instructs a running job to terminate with error,
 (Except when that job is READY, which produces no error.)
>>
>> CANCEL will take a job to either NULL... (this is the early abort
>> pathway, prior to the job being fully realized.)
>>
>> ...or to ABORTING (from CREATED once it has fully realized the job, or
>> from RUNNING, READY, WAITING, or PENDING.)
>>
 PAUSE   Request a job to pause.
>>
>> issued to RUNNING or READY, transitions to PAUSED or STANDBY respectively.
>>
 RESUME  Request a job to resume from a pause.
>>
>> issued to PAUSED or STANDBY, transitions to RUNNING or READY respectively.
>>
 SET-SPEED   Change the speed limiting parameter of a job.
>>
>> No run state change.
>>
 COMPLETEAsk a READY job to finish and exit.

>>
>> Issued to a READY job, transitions to WAITING.
>>
 FINALIZEAsk a PENDING job to perform its graph finalization.
>>
>> Issued to a PENDING job, transitions to CONCLUDED.
>>
 DISMISS Finish cleaning up an empty job.
>>>
>>
>> Issued to a CONCLUDED job, transitions to NULL.
>>
>>
 And here's my stab at a diagram:

  +-+
  |UNDEFINED|
  +--+--+
 |
  +--v+
+-+CREATED+-+
| +--++ |
||  |
| +--++ +--+|
+-+RUNNING<->PAUSED||
| +--+-+--+ +--+|
|| ||
|| +--+ |
||| |
| +--v--+   +---+ | |
+-+READY<--->STANDBY| | |
| +--+--+   +---+ | |
||| |
| +--v+   | |
+-+WAITING<---+ |
| +--++ |
||  |
| +--v+ |
+-+PENDING| |
| +--++ |
||  |
 +--v-+   +--v--+   |
 

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

[Markus Armbruster]

John Snow  writes:

> On 04/17/2018 09:44 AM, Markus Armbruster wrote:
>> John Snow  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
>>> ABORTINGJob is aborting or has been cancelled
>>> CONCLUDED   Job has finished and has a retcode available
>>> NULLJob is being dismantled. Internal state only.
>>>
>>> Job Verbs:
>>>
>
> Backporting your quote up here:
>
>> For each job verb and job state: what's the new job state?
>>
>
> That's not always 1:1, though I tried to address it in the commit messages.

Let me rephrase my question then.  For each job verb and job state: what
are the possible new job states?  If there's more than one, what's the
condition for each?

I appreciate commit messages explaining that, but having complete state
machine documentation in one place (a comment or in docs/) would be
nice, wouldn't it?

>>> CANCEL  Instructs a running job to terminate with error,
>>> (Except when that job is READY, which produces no error.)
>
> CANCEL will take a job to either NULL... (this is the early abort
> pathway, prior to the job being fully realized.)
>
> ...or to ABORTING (from CREATED once it has fully realized the job, or
> from RUNNING, READY, WAITING, or PENDING.)
>
>>> PAUSE   Request a job to pause.
>
> issued to RUNNING or READY, transitions to PAUSED or STANDBY respectively.
>
>>> RESUME  Request a job to resume from a pause.
>
> issued to PAUSED or STANDBY, transitions to RUNNING or READY respectively.
>
>>> SET-SPEED   Change the speed limiting parameter of a job.
>
> No run state change.
>
>>> COMPLETEAsk a READY job to finish and exit.
>>>
>
> Issued to a READY job, transitions to WAITING.
>
>>> FINALIZEAsk a PENDING job to perform its graph finalization.
>
> Issued to a PENDING job, transitions to CONCLUDED.
>
>>> DISMISS Finish cleaning up an empty job.
>> 
>
> Issued to a CONCLUDED job, transitions to NULL.
>
>
>>> 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
>> 

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

[John Snow]

On 04/17/2018 09:44 AM, Markus Armbruster wrote:
> John Snow  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
>> ABORTINGJob is aborting or has been cancelled
>> CONCLUDED   Job has finished and has a retcode available
>> NULLJob is being dismantled. Internal state only.
>>
>> Job Verbs:
>>

Backporting your quote up here:

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

That's not always 1:1, though I tried to address it in the commit messages.


>> CANCEL  Instructs a running job to terminate with error,
>> (Except when that job is READY, which produces no error.)

CANCEL will take a job to either NULL... (this is the early abort
pathway, prior to the job being fully realized.)

...or to ABORTING (from CREATED once it has fully realized the job, or
from RUNNING, READY, WAITING, or PENDING.)

>> PAUSE   Request a job to pause.

issued to RUNNING or READY, transitions to PAUSED or STANDBY respectively.

>> RESUME  Request a job to resume from a pause.

issued to PAUSED or STANDBY, transitions to RUNNING or READY respectively.

>> SET-SPEED   Change the speed limiting parameter of a job.

No run state change.

>> COMPLETEAsk a READY job to finish and exit.
>>

Issued to a READY job, transitions to WAITING.

>> FINALIZEAsk a PENDING job to perform its graph finalization.

Issued to a PENDING job, transitions to CONCLUDED.

>> DISMISS Finish cleaning up an empty job.
> 

Issued to a CONCLUDED job, transitions to NULL.


>> 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.
> 

Apparently yes. :\

(Secretly fixed up in my reply.)

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

Can you recommend a tool to help me do that? I've been using asciiflow
infinity (http://asciiflow.com) and it's not very good, but I don't have
anything better.

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

(1) The CONCLUDED state allows jobs to persist in the job query list

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

[Markus Armbruster]

Forgot to mention: yes, I know this has been merged already.  I'm merely
trying to catch up with recent block layer progress.

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

[Markus Armbruster]

John Snow  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
> ABORTINGJob is aborting or has been cancelled
> CONCLUDED   Job has finished and has a retcode available
> NULLJob 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.
> COMPLETEAsk a READY job to finish and exit.
>
> FINALIZEAsk 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)?

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

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20180310082746.24198-1-js...@redhat.com
Subject: [Qemu-devel] [PATCH v5 00/21] blockjobs: add explicit job management

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/1520692378-1835-1-git-send-email-lidongc...@tencent.com -> 
patchew/1520692378-1835-1-git-send-email-lidongc...@tencent.com
 * [new tag]   
patchew/1520716927-17068-1-git-send-email-zhangc...@gmail.com -> 
patchew/1520716927-17068-1-git-send-email-zhangc...@gmail.com
 * [new tag]   
patchew/1520723090-22130-1-git-send-email-li...@roeck-us.net -> 
patchew/1520723090-22130-1-git-send-email-li...@roeck-us.net
 * [new tag]   
patchew/1520754314-5969-1-git-send-email-zhangc...@gmail.com -> 
patchew/1520754314-5969-1-git-send-email-zhangc...@gmail.com
 * [new tag]   
patchew/1520839658-20499-1-git-send-email-th...@redhat.com -> 
patchew/1520839658-20499-1-git-send-email-th...@redhat.com
 * [new tag]   
patchew/152084575964.24079.3708480492746701627.st...@bahia.lan -> 
patchew/152084575964.24079.3708480492746701627.st...@bahia.lan
 * [new tag]   
patchew/1520849818-6915-1-git-send-email-anton.nefe...@virtuozzo.com -> 
patchew/1520849818-6915-1-git-send-email-anton.nefe...@virtuozzo.com
 * [new tag]   
patchew/1520850690-23245-1-git-send-email-abdallah.bouass...@lauterbach.com -> 
patchew/1520850690-23245-1-git-send-email-abdallah.bouass...@lauterbach.com
 t [tag update]
patchew/20180309165212.97144-1-vsement...@virtuozzo.com -> 
patchew/20180309165212.97144-1-vsement...@virtuozzo.com
 * [new tag]   patchew/20180309172713.26318-1-kw...@redhat.com -> 
patchew/20180309172713.26318-1-kw...@redhat.com
 t [tag update]patchew/20180309175453.41548-1-dgilb...@redhat.com 
-> patchew/20180309175453.41548-1-dgilb...@redhat.com
 t [tag update]
patchew/20180309182202.31206-1-faro...@linux.vnet.ibm.com -> 
patchew/20180309182202.31206-1-faro...@linux.vnet.ibm.com
 * [new tag]   patchew/20180310082746.24198-1-js...@redhat.com -> 
patchew/20180310082746.24198-1-js...@redhat.com
 * [new tag]   patchew/20180310214554.157155-1-ebl...@redhat.com -> 
patchew/20180310214554.157155-1-ebl...@redhat.com
 * [new tag]   patchew/20180311201239.25506-1-nia.ala...@gmail.com 
-> patchew/20180311201239.25506-1-nia.ala...@gmail.com
 * [new tag]   patchew/20180312094308.21716-1-pbonz...@redhat.com 
-> patchew/20180312094308.21716-1-pbonz...@redhat.com
 * [new tag]   patchew/20180312104241.24965-1-kra...@redhat.com -> 
patchew/20180312104241.24965-1-kra...@redhat.com
 * [new tag]   patchew/20180312105941.15439-1-kra...@redhat.com -> 
patchew/20180312105941.15439-1-kra...@redhat.com
 * [new tag]   patchew/20180312110532.30967-1-kra...@redhat.com -> 
patchew/20180312110532.30967-1-kra...@redhat.com
Switched to a new branch 'test'
68abd0377d tests/test-blockjob: test cancellations
de58cfc7f7 iotests: test manual job dismissal
f39d922c64 blockjobs: Expose manual property
b488c52fc3 blockjobs: add block-job-finalize
eb5fcb71bb blockjobs: add PENDING status and event
0069db2cf3 blockjobs: add waiting status
9fed33f1b8 blockjobs: add prepare callback
4b3e0a2c89 blockjobs: add block_job_txn_apply function
f1c8da8844 blockjobs: add commit, abort, clean helpers
bde9d79765 blockjobs: ensure abort is called for cancelled jobs
7fb719574c blockjobs: add block_job_dismiss
960357f88d blockjobs: add NULL state
d55cd56bc8 blockjobs: add CONCLUDED state
5c9762922f blockjobs: add ABORTING state
fa1056efe6 blockjobs: add block_job_verb permission table
10f12bcc22 iotests: add pause_wait
0c88b0db61 blockjobs: add state transition table
53301418d9 blockjobs: add status enum
fca226d934 Blockjobs: documentation touchup
d8a93c4755 blockjobs: model single jobs as transactions
158eee13ab blockjobs: fix set-speed kick

=== OUTPUT BEGIN ===
Checking PATCH 1/21: blockjobs: fix set-speed kick...
Checking PATCH 2/21: blockjobs: model single jobs as transactions...
Checking PATCH 3/21: Blockjobs: documentation touchup...
Checking PATCH 4/21: blockjobs: add status enum...
Checking PATCH 5/21: blockjobs: add state transition table...
ERROR: space prohibited before