Difference between revisions of "TaskFlow/Persistence"
(→Checkpointing) |
(→Task detail) |
||
| Line 41: | Line 41: | ||
Stores all of the information associated with one specific run instance of a [[StructuredWorkflowPrimitives|task]]. | Stores all of the information associated with one specific run instance of a [[StructuredWorkflowPrimitives|task]]. | ||
| − | + | {| class="wikitable" | |
| − | + | |+Task details | |
| − | + | |- | |
| − | + | |Name | |
| − | + | |Description | |
| − | + | |- | |
| + | |State | ||
| + | |State of the task | ||
| + | |- | ||
| + | |Results | ||
| + | |Results that the task may have produced | ||
| + | |- | ||
| + | |Exception | ||
| + | |Serialized exception that the task may have produced | ||
| + | |- | ||
| + | |Stack trace | ||
| + | |Stack trace of the exception that the task may have produced | ||
| + | |- | ||
| + | |Meta | ||
| + | |JSON blob of non-indexable associated task information | ||
| + | |} | ||
== Checkpointing == | == Checkpointing == | ||
Revision as of 02:18, 24 August 2013
Revised on: 8/24/2013 by Harlowja
Contents
Overview
A persistence API as well as root persistence types are provided with taskflow for the purpose of ensuring that jobs, flows, and there associated tasks can be backed up in a database or in memory. The user, when configuring the persistence API, has the option to specify which backend is desired and subsequently store and retrieve the data associated with the jobs, flows, and tasks in use. Retrieval and storage, when desired, are performed by making use of the root persistence types (i.e. LogBook, FlowDetails, and TaskDetails).
Why?
- Allows for reconstruction and resumption of flows and there associated tasks.
- Allows for redundant checks that expected data is provided.
- Allows for the user to view the history of a jobs, flows and there associated tasks.
- Facilitates debugging of taskflow usage and integration (and runtime/post-runtime analysis).
Backends
Configuration
When configuring the backend to use, a string is provided to specify how the data is to be stored. The options currently available for use are detailed below.
Options
- SQLAlchemy:
- Makes use of the sqlalchemy library to store all data in a SQLite (or postgres or mysql) database.
- Will be persisted in the event of a system failure.
- In-memory:
- Makes use of a in-memory dictionaries to store data in memory in a thread-safe manner.
- Will NOT be persisted in the event of a system failure.
- More to come...
Types
Regardless of the backend chosen to persist taskflow data, the generic API (taskflow.persistence.backends.api) must always return one of the following types. These are the basic types with which the user will interface with the backend. When requested from the backend, the returned generic types are a snapshot of the data stored in the backend. Any changes made to the generic types may not be automatically updated in the backend, rather only when the user calls the save method of the changed object.
Logbook
- Stores a collection of flow details + any metadata about the logbook (last_updated, deleted, name...).
- Typically connected to job with which the logbook has a one-to-one relationship.
- Provides all of the data necessary to automatically reconstruct a job object.
Flow detail
- Stores a collection of task details, metadata about the flow and potentially any task relationships.
- Persistence representation of a specific run instance of a flow.
- Provides all of the details necessary for automatic reconstruction of a flow object.
Task detail
Stores all of the information associated with one specific run instance of a task.
| Name | Description |
| State | State of the task |
| Results | Results that the task may have produced |
| Exception | Serialized exception that the task may have produced |
| Stack trace | Stack trace of the exception that the task may have produced |
| Meta | JSON blob of non-indexable associated task information |
Checkpointing
A WIP topic/discussion is the concept of checkpointing:
See: Checkpointing
Contributors
Kevin Chen (Rackspace)
Joshua Harlow (Yahoo!)
Jessica Lucci (Rackspace)
