Difference between revisions of "EventScheduler"
Adrian Otto (talk | contribs) (→Event Creation) |
Adrian Otto (talk | contribs) |
||
Line 1: | Line 1: | ||
+ | * '''Created''': 2013-05-02 | ||
+ | * '''Contributors''': Adrian Otto | ||
+ | |||
+ | __TOC__ | ||
+ | |||
== Proposal Only == | == Proposal Only == | ||
− | Please recognize that this is only a proposed service to be considered for development. This is NOT YET IMPLEMENTED | + | Please recognize that this is only a proposed service to be considered for development. This is NOT YET IMPLEMENTED. |
== Overview == | == Overview == |
Revision as of 23:05, 3 May 2013
- Created: 2013-05-02
- Contributors: Adrian Otto
Contents
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. A discussion on our Dev ML[1][2] 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
- ↑ http://lists.openstack.org/pipermail/openstack-dev/2013-April/008307.html
- ↑ http://lists.openstack.org/pipermail/openstack-dev/2013-May/008332.html
Scope
An API service for allowing for a future event to be triggered, or repeatedly triggered on a regular schedule until deletion. Offer the ability to:
- Register a
webhook
that will be executed at a specific future time. - Register a that will be executed repeatedly once per specified time interval.
The only job of this service is to trigger a webhook
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
- 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.
- 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:
Verb | URI | Description |
---|---|---|
GET | /{tenant_id}/events | List existing scheduled events |
GET | /{tenant_id}/events/{id} | Get event details |
PUT | /{tenant_id}/events | Create a new event |
DELETE | /{tenant_id}/events/{id} | Delete an event |
Event Creation
Verb | URI | Description |
---|---|---|
PUT | /{tenant_id}/events | Create a new event |
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:
Attribute | Required | Description |
---|---|---|
name |
N | A short descriptive string assigned upon creation to identify the task. |
webhook |
Y | The webhook URL that the event scheduler system will trigger on the specified interval. |
delete_webhook |
N | The webhook URL that the event scheduler system will trigger if the timeout is reached, or overlap_policy triggers.
|
run_at_epoch_seconds |
OR | The unix epoch time (seconds since 1970-01-01 00:00:00 GMT) to start the task. May not be combined with interval_seconds or overlap_policy .
|
interval_seconds |
OR | The frequency in seconds that this task will be triggered on. May not be combined with run_at_epoch_seconds .
|
overlap_policy |
N | How to handle the situation there the previous task's completion_webhook was not called before the start of the subsequent start time. Available policies: skip: Do not start an overlapping task. May not be combined with run_at_epoch_seconds .delete: Delete the prior task using the delete_webhook (kill/rollback the task in the task system)default: Start another task |
timeout_seconds |
N | Number of seconds to wait before calling delete_webhook if completion_webhook is not called first. Default: 3600
|
NOTE: Either run_at_epoch_seconds
or interval_seconds
must be supplied. If both are present, or both are absent a "400 Bad Request" error must be returned.
One-Time Events
If the run_at_epoch_seconds
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 run_at_epoch_seconds
+timeout_seconds
. 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
Verb | URI | Description |
---|---|---|
GET | /{tenant_id}/events/{id} | 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:
Attribute | Description |
---|---|
id |
The server-assigned id string of the scheduled event |
name |
A short descriptive string assigned upon creation to identify the task. |
webhook |
The webhook URL that the event scheduler system will trigger on the specified interval. |
delete_webhook |
The webhook URL that the event scheduler system will trigger if the timeout is reached, or overlap_policy triggers.
|
completion_webhook |
The webhook that the task executor must call to mark this task as completed in the EventScheduler system. |
run_at_epoch_seconds |
The unix epoch time (seconds since 1970-01-01 00:00:00 GMT) to start the task. |
interval_seconds |
The frequency in seconds that this task will be triggered on. |
overlap_policy |
How to handle the situation there the previous task's completion_webhook was not called before the start of the subsequent start time. Available policies: skip: Do not start an overlapping task. May not be combined with run_at_time .delete: Delete the prior task using the delete_webhook (kill/rollback the task in the task system)default: Start another task |
timeout_seconds |
Number of seconds to wait before calling delete_webhook if completion_webhook is not called first. Default: 3600
|
last_run_epoch_seconds |
The unix epoch time (seconds since 1970-01-01 00:00:00 GMT) the last task was started. Default: 0 |
status |
Indicate the status of the event, in accordance with the Event Lifecycle |
Event Lifecycle
State | Description |
---|---|
IDLE | The task is not running, and will be scheduled to run in the future. |
RUNNING | The task for this event has been started and is running. The completionWebhook has not yet been called.
|
TIMEOUT | The task has been timed out after timeoutSeconds , and the deleteWebhook is being called.
|
ERROR | The task could not be started because the POST request to the webhook URL failed.
|
Triggering Tasks
Scheduled events
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 webhook
URL. This will inform the task execution system of the completionWebhook
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.
Use Cases
# | Project | Description |
---|---|---|
1 | Nova | Scheduled Images |
2 | Heat | Scheduled Autoscale (Scale up/down resources on a pre-determined schedule) |
N | Yours | Add yours here please |
Pending Questions
- What features should be included?
- 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.
- Are there volunteers to work on this?