|
|
| (34 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | == Flow States ==
| + | '''Revised on:''' {{REVISIONMONTH1}}/{{REVISIONDAY}}/{{REVISIONYEAR}} by {{REVISIONUSER}} |
| | | | |
| − | [[File:Tf flow state diagram.png|150px|thumb|Flow state diagram]]
| + | __TOC__ |
| − | | + | The page was moved to developers documentation: http://docs.openstack.org/developer/taskflow/states.html |
| − | Flow starts its life in '''PENDING''' state. Then, when it is run, it transitions to '''RUNNING''' state, and stays that state unitl it is finished; then if all tasks finishshed successfully flow transitions to '''SUCCESS''' state or, in case of failure, to '''FAILURE''' state.
| |
| − | | |
| − | From '''FAILURE''' state flow is reverted; when it happens, flow first transitions to '''REVERTING''' state, then revert happens, then flow transitions to '''REVERTED''' state if revert is completed succesfully, or to '''FAILURE''' if some tasks failed to revert.
| |
| − | | |
| − | In '''RUNNING''' and '''REVERTING''' state flow can be suspended. When this happens, flow transitions to '''SUSPENDING''' state immediately.
| |
| − | In that state engine waits for running tasks to finish. Then, when no tasks are running and all results receivced so far are saved,
| |
| − | flow leaves '''SUSPENDING''' state. It may go to '''SUCCESS''' if all tasks were in fact run, or to "REVERTED" if flow was reverting and all tasks were reverted while engine were waiting, or to '''FAILURE''' if tasks were run or reverted and some of them failed, but in most common case flow transitions to '''SUSPENDED'''. From '''SUSPENDED''' flow can run on (transition back to '''RUNNING''') or be reverted (and transition to '''REVERTING''' state).
| |
| − | | |
| − | When is interrupted 'in a hard way' (e.g. server crashes), it can be loaded from storage in any state. If the state is not
| |
| − | '''PENDING''' (flow was never run) or '''SUCCESS''', '''FAILURE''' or '''REVERTED''' (in which case flow is already finished), flow
| |
| − | gets to '''RESUMING''' state for the short time period when it is loaded from database (this transitions is not shown
| |
| − | on diagram). When flow is finally loaded from database, it goes to '''SUSPENDED''' state.
| |
| − | | |
| − | From '''SUCCESS''', '''FAILURE''' or '''REVERTED''' flow can be run again (and thus it goes to '''RUNNING'''' state). One of possible use cases for this transition if flow or flow details were altered after flow is finished, and client code wants to ensure that each task from updated flow had its chance to run.
| |
| − | | |
| − | Current code checks each transition for flow states against model described above and raises <code>InvalidStateException</code> if invalid transition is attempted. This usualy means there is some kind of bug in engine, and should be reported as such.
| |
| − | | |
| − | <br clear=all>
| |
| − | | |
| − | == Task States ==
| |
| − | | |
| − | [[File:Tf task state diagram.png|150px|thumb|Task state diagram]]
| |
| − | | |
| − | When task just added to the flow, it is in '''PENDING''' state, which means it can be executed or waits for all of task it depends on to complete. Then, when task is executed, it transitions to '''RUNNING''' state, and stays in it until its <code>execute()</code> method returns. When task is finished, it transitions to '''SUCCESS''' state if it was finished successfully, or to '''FAILURE''' state if not.
| |
| − | | |
| − | When flow is reverted, all tasks in '''PENDING''' state are left as is; tasks from all the other states transition to '''REVERTING''' state, and their <code>revert()</code> method is called. When that method returns, task transitions to '''REVERTED''' state, and then to '''PENDING'''.
| |
| − | | |
| − | Transition from '''RUNNING''' to '''REVERTING''' state happens when task was interrupted while running, and then revert occurs. This may take place e.g. when daemon is killed while running the task.
| |
| − | | |
| − | Transition from '''REVERTED''' to '''PENDING''' state happens immediately. The main purpose of '''REVERTED''' state is notifications.
| |
| − | | |
| − | <br clear=all>
| |
| − | | |
| − | === Vendor-Specific States ===
| |
| − | | |
| − | Tasks that are running vendor-specific code can have some other states to implement some custom logic/notifications and change task's metadata. However transitions between such vendor-specific states are enclosed in one of common states which are shown in the diagram.
| |
| − | | |
| − | For example task's state transitions can be:
| |
| − | | |
| − | <code>PENDING --> RUNNING --> (any vendor specific states/transitions) --> RUNNING --> SUCCESS</code>
| |
| − | | |
| − | '''Note:''' there should likely be a way to make <code>(any vendor specific states/transitions)</code> configurable in that the vendor specific states/transitions may not need to be persisted to permanent storage. Perhaps a task property maybe appropriate?
| |
