Difference between revisions of "StructuredWorkflowPrimitives"
(→Relevant Links) |
(→Structured Workflow Primitives) |
||
| Line 9: | Line 9: | ||
* https://wiki.openstack.org/wiki/StructuredStateManagement | * https://wiki.openstack.org/wiki/StructuredStateManagement | ||
* https://wiki.openstack.org/wiki/StructuredStateManagementDetails | * https://wiki.openstack.org/wiki/StructuredStateManagementDetails | ||
| + | |||
| + | === Reviews === | ||
| + | |||
| + | * https://review.openstack.org/#/c/27869/ | ||
=== Primitives === | === Primitives === | ||
| Line 22: | Line 26: | ||
=== Locks === | === 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 | + | 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 single machine lock (useful for dev/test) possibly using the existing nova/oslo file locking functionality. |
=== Ownership === | === 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). | + | 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' (similar to the physical concept of a ''job board''), 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 === | === 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 | + | 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 (or zookeeper backed) task log 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. |
=== Reservations === | === Reservations === | ||
=== Reserve/configure/acquire (or release) semantics === | === Reserve/configure/acquire (or release) semantics === | ||
Revision as of 23:41, 3 May 2013
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/StructuredStateManagement
- https://wiki.openstack.org/wiki/StructuredStateManagementDetails
Reviews
Primitives
Tasks
This would forms the underlying workflow component, it would be a simple object likely with apply() and revert() methods. It would perform some action, which revert() could attempt to undo (if applicable).
Workflows
Workflows would be a set of common patterns that order tasks in various ways but would be separated from the task itself. You could imagine that a workflow could be [get up in the morning, take shower, go to work]. Each task there could be independently applied but this would likely not be the correct sequence. A common linear sequence would likely be the correct ordering. This would be one example of a pattern that a set of tasks would go through (aka a linear workflow), one that should not need to have code duplicated to accomplish. Such a set of common patterns that perform said workflow (where tasks are attached to said workflow pattern) would be very useful to have to avoid creating arbitrary and ad-hoc workflows.
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 single machine lock (useful for dev/test) possibly using the existing nova/oslo file locking functionality.
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' (similar to the physical concept of a job board), 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 (or zookeeper backed) task log 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.
