EventScheduler


 * Created: 2013-05-02
 * Contributors: Adrian Otto

Proposal Only
Please recognize that this is only a proposed service to be considered for development. This is NOT YET IMPLEMENTED.

Overview
Both Nova and Heat (Autoscale) have a need to kick off regularly scheduled task flows. We expect that it may be convenient to trigger Heat Orchestrations as well, which may in turn trigger Convection task flows or jobs in Qonos. A discussion on our Dev ML about scheduled snapshots in Nova has made it clear that this would be useful as a general purpose service that multiple projects could utilize.

In the spirit of Gall's Law we wish to create something simple, functional, and useful that can be evolved over time to support a wider range of utility.

ML References
that will be executed at a specific future time.
 * 1) Register a  that will be executed repeatedly once per specified time interval.

The only purpose of this service is to trigger a  at the specified future time, or on the indicated time interval.

NOTE: The actual start time of the event is not guaranteed, but the attempt to start such an event at least once every cycle of the interval is guaranteed.

Out of Scope

 * 1) This system is not concerned with the tasks or scripts that will be run. Such task creation and execution thereof will happen in an external system such as Convection. Such a system may trigger an Orchestration in Heat, which involves submitting an orchestration template to the Heat API.
 * 2) This system is not concerned with cron syntax, or any localized timezone concerns. If those features are desired they can be implemented using this system as a fundamental building block.

API
Synopsis:

Event Creation
Schedule a recurring event to run once per 24 hours: {   "name": "Nightly Snapshot Trigger", "webhook": "http://example.org/aabbccdd", "delete_webhook": "http://example.org/aabbccdd834903", "interval_seconds": "86400", "overlap_policy", "kill", "timeout_seconds": 3600 } Schedule single event to run at a future date {   "name": "Nightly Snapshot Trigger", "webhook": "http://example.org/aabbccdd", "delete_webhook": "http://example.org/aabbccdd834903", "run_at_epoch_seconds": "1399057324", "timeout_seconds": 3600 }

Request Attributes:

NOTE: Either  or   must be supplied. If both are present, or both are absent a "400 Bad Request" error must be returned.

One-Time Events
If the  attribute is used to indicate a specific future run time for the task, the system may execute it at that precise time, or some time after that time, and before  +. If the system can not guarantee to trigger the even during this window, then an error may be returned to refuse the PUT request. (Error code TBD).

Get Event Details
{   "id": "aaaaaa-bbbbb-cccc-dddd-eee", "name": "Nightly Snapshot Trigger", "webhook": "http://example.org/aabbccdd", "delete_webhook": "http://example.org/aabbccdd834903", "completion_webhook": "http://example.org/aabbccdd78437834798382782", "interval_seconds": "86400", "overlap_policy", "skip", "timeout_seconds": "3600", "last_run_epoch_seconds", "1367519917", "status", "IDLE" }

Response Attributes:

Triggering Tasks
Scheduled  trigger task flows (aka: workflows) in an external system (probably Convection) by using a webhook. The output of a GET on that single event will be passed in the body of the POST to the specified  URL. This will inform the task execution system of the  to call when it finishes the task.

Security
The webhooks will need to be signed in a way that the receiver of the webhook (most likely Convection) will be able to authenticate the request, and take the appropriate action. We may want a feature that restricts the domains that are allowed in the URL of the supplied webhooks.

Pending Questions

 * 1) What features should be included?
 * 2) Where should the service be incubated, and if/how it should be integrated with Oslo? The answer to this should indicate where the blueprints should be filed.
 * 3) Are there volunteers to work on this?