StructuredWorkflowPrimitives

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

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 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.