Quick drive-by comment: Kevin Wolf <kw...@redhat.com> writes:
[...] > Let me try to just consolidate all of the above into a single state > machine: > > 1. CREATED --> RUNNING > driver callback: .start > 2a. RUNNING --> READY | CANCELLED > via: auto transition (when bulk copy is finished) / block-job-cancel > event: BLOCK_JOB_READY > 2b. READY --> READY (COMPLETING) | READY (CANCELLING) > via: block-job-complete / block-job-cancel > event: none > driver callback: .complete / none > 3. READY (CANCELLING | COMPLETING) --> DONE > via: auto transition > (CANCELLING: after draining in-flight mirror requests; > COMPLETING: when images are in sync) > event: BLOCK_JOB_DONE > 4. DONE --> PENDING > via: auto transition (all jobs in the transaction are DONE) > event: BLOCK_JOB_PENDING > 5. PENDING --> FINISHED > via: block-job-finalize > event: COMPLETED | CANCELLED > driver callback: .prepare_finalize / .commit / .abort > 6. FINISHED --> NULL > via: block-job-reap > event: none > driver callback: .clean > > I removed COMPLETED/CANCELLED states because they are never externally > visible. You proposed an "auto transition" there, but the transition > would be immediately after the previous one, so clients always see > PENDING --> NULL | FINISHED. > > We would have two booleans to make explicit transition automatically: > > auto-finalize for block-job-finalize (default: true) > auto-reap for block-job-reap (default: true) Are we *sure* we need to quadruple the test matrix? What exactly is the use case for either of these two flags? > Both of them would be executed automatically as soon as the respective > commands would be available. > > We could add more auto-* options for the remaining explicit transition *groan* > (block-job-complete/cancel in READY), but these are not important for > the problems we're trying to solve here. They might become interesting > if we do decide that we want a single copy block job instead of doing > similar things in mirror, commit and backup. > The naming needs some improvements (done -> pending -> finished looks > really odd), but does this make sense otherwise? > > Kevin
