John Snow <js...@redhat.com> 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)?
