Copyright 2015, EMC, Inc.

job network/graph runner

rm -rf node_modules
npm install

Note: requires RabbitMQ and mongod (if using the waterline/mongo driver) to be running to start and test correctly.

sudo node index.js

To interact with the system externally, e.g. running graphs against live systems, you need to be running the following services:

• on-http (mandatory for all)
• on-dhcp (mandatory for node graphs)
• on-tftp (mandatory for node booting graphs)

This repository provides functionality for running encapsulated jobs/units of work via graph-based control flow mechanisms. For example, a typical graph consists of a list of tasks, which themselves are essentially decorated functions. The graph definition specifies any context and/or option values that should be handed to these functions, and more importantly, it provides a mechanism for specifying when each task should be run. The most simple case is saying a task should be run only after a previous task has succeeded (essentially becoming a state machine). More complex graphs may involve event based task running, or defining data/event channels that should exist between concurrently running tasks.

When running the on-http process, these are some common API commands you can send:

Get available graphs

GET
/api/common/workflows/library

Run a new graph against a node

Find the graph definition you would like to use, and copy the top-level injectableName attribute

POST
/api/common/nodes/<id>/workflows
{
    name: <graph name>
}

This will return a serialized graph object.

Query an active graph's state

GET
/api/common/nodes/<id>/workflows/active

Create a new graph definition

PUT
/api/common/workflows
{
    <json definition of graph>
}

Graphs are defined via a JSON definition that conform to this schema:

• friendlyName (string): a human readable name for the graph
• injectableName (string): a unique name used by the system and the API to refer to the graph
• tasks (array of objects): a list of task definitions or references to task definitions. For an in-depth explanation of task definitions, see the on-tasks README
  • tasks.label (string): a unique string to be used as a reference within the graph definition
  • tasks.[taskName] (string): the injectableName of a task in the database to run. This or taskDefinition is required.
  • tasks.[taskDefinition] (object): an inline definition of a task, instead of one in the database. This or taskName is required.
  • tasks.[ignoreFailure] (boolean): ignoreFailure: true will prevent the graph from failing on task failure
  • tasks.[waitOn] (object): key, value pairs referencing other task labels to desired states of those tasks to trigger running on. Available states are 'succeeded', and 'failed' and 'finished' (run on succeeded or failed). If waitOn is not specified, the task will run on graph start.
• [options]
  • options.[defaults] (object): key, value pairs that will be handed to any tasks that have matching option keys
  • options.<label> (object): key, value pairs that should all be handed to a specific task

To run in debug mode:

sudo node debug index.js

To run tests from a developer console:

npm test

To run tests and get coverage for CI:

# verify hint/style
./node_modules/.bin/jshint -c .jshintrc --reporter=checkstyle lib index.js > checkstyle-result.xml || true
./node_modules/.bin/istanbul cover -x "**/spec/**" _mocha -- $(find spec -name '*-spec.js') -R xunit-file --require spec/helper.js
./node_modules/.bin/istanbul report cobertura
# if you want HTML reports locally
./node_modules/.bin/istanbul report html