Jump to: navigation, search

TaskFlow/Persistence

< TaskFlow
Revision as of 20:43, 5 August 2013 by Kchenweijie (talk | contribs) (Created page with "== Overview == A persistence API as well as generic persistence types are provided with the TaskFlow project for the purpose of ensuring that Jobs, Flows, and Tasks can be bac...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Overview

A persistence API as well as generic persistence types are provided with the TaskFlow project for the purpose of ensuring that Jobs, Flows, and 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 generic persistence types i.e. LogBook, FlowDetails, and TaskDetails. Each of these generic types has the ability to save itself to the backend and are also returned by default by the persistence API's getter methods.

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

  • SQLite ('db_backend'):
    • Makes use of the sqlalchemy library to store all data in a SQLite table
    • Will be persisted in the event of a system failure
  • In-memory ('mem_backend'):
    • Makes use of a LockingDict class to store data in memory in thread-safe dicts
    • Will NOT be persisted in the event of a system failure
  • More to come...

Generic Types

Regardless of the backend chosen to persist TaskFlow data, the generic API (taskflow.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 will 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 FlowDetails
  • Persistence representation of a Job with which the LogBook has a one-to-one relationship
  • Provides all of the data necessary to automatically reconstruct a Job object

FlowDetail

  • Stores a collection of TaskDetails and TaskDetail relations
  • Persistence representation of a specific run instance of a Flow
  • Provides all of the TaskDetails and TaskDetail relations necessary for automatic reconstruction of a Flow object

TaskDetail

  • Stores all of the information associated with one specific run instance of a Task:
    • state
    • results
    • exception
    • stacktrace
    • metadata

Why?

  • allows for reconstruction and resumption of Flows
  • allows for redundant checks that expected data is provided
  • allows for the user to view the history of a Jobs, Flows, and Tasks
  • facilitates debugging of TaskFlow

Contributors

Kevin Chen (Rackspace)
Joshua Harlow (Yahoo!)
Jessica Lucci (Rackspace)