Re: [Qemu-block] [Qemu-devel] [PATCH v5 00/21] blockjobs: add explicit job management
John Snowwrites: > 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
On 04/18/2018 03:25 AM, Markus Armbruster wrote: > John Snowwrites: > >> 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
John Snowwrites: > 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
On 04/17/2018 09:44 AM, Markus Armbruster wrote: > John Snowwrites: > >> 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
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
John Snowwrites: > 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
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