Heat/ConvergenceDesignNotesByMike

Convergence Design Notes by Mike

In the Juno design summit etherpad (https://etherpad.openstack.org/p/heat-workflow-vs-convergence) there are several design problems and solutions discussed, with final selection unclear. In this page I offer one opinion. The contentious issues include: to use a workflow engine or not, whether and (if so) how to chunk the work.

Workflow Engine or Not

The desires to support large stacks (size of 1E6 resources was mentioned) and react quickly to new stack operations appears to have side-tracked the idea of using a workflow engine. Here is my net of the issues. Suppose a workflow engine with a clean interrupt operation: it stops the workflow engine from launching new actions, and waits for completion of the actions currently in progress. Heat could use such a workflow engine. When some differences between target and observed state are detected, heat would compose a workflow to heal the differences and launch it. If later more differences are detected before that workflow completes, that workflow would be interrupted and then a new workflow composed and launched to handle all the current differences. This would probably entail yet an additional copy of state: in addition to target and observed state there would be another kind of state that is observed state overwritten by the goals of the workflow currently in progress. The kind of difference that causes a new/revised workflow is a difference between that third kind of state and target state.