StructuredWorkflowPrimitives
Contents
Structured Workflow Primitives
Rationale
This wiki can be used to document some of the core foundational pieces of a workflow primitive library.
Relevant Links
- https://wiki.openstack.org/wiki/StructuredStateManagementDetails
- https://etherpad.openstack.org/the-future-of-orch
Potential primitives
Tasks
This would forms the underlying workflow component, it would be a simple object likely with apply() and revert() methods
Locks
There needs to be a concept of a lock on a given workflow (and later resources) which can be used to guarantee said workflow is only worked on by one entity. There could be room for a ZK based lock, a DB based lock or a memory based lock (useful for dev/test).
Ownership
There needs to be a concept of a single owner of a workflow, this can be used to identify the individual entity working on said workflow at any given moment. The workflow ownership process could be ZK based or DB based. One could imagine a workflow ownership 'service', which would be used to transfer an actionable piece of work from something like the nova-api to another entity and a API extensions to determine the current entity processing a workflow and its status and depending on the backing ownership service there could be further extensions that allow for manual transfer of failed workflows to other 'entities' (the ZK impl. could likely do this automatically so may not need said extensions).
Task log with metadata
In order to be able to do resumption of tasks there needs to be enough associated history for what tasks/workflows have occurred to be able to have said workflow ownership be resumable. Likely there can be a database task log (something similar already exists) with a concept of tasks/workflows that have occurred and for each task/workflow there would be a reference to a description of what occurred (the metadata part). Both the log and the associated would be needed in order to do correct rollback.