Deltacloud Tracker Design (Draft)

David Lutterkort lutter at redhat.com
Fri Jun 8 10:31:32 UTC 2012


[ Adding dev at deltacloud ]

On Thu, 2012-06-07 at 21:15 +0200, Jan Provazník wrote:
> Hi Lutter,
> Michal pointed me to your draft of Tracker design which looks great. 
> Couple of notes are inline. Sending it to aeolus-devel list too so 
> others can join.
> 
> Original doc can be found here:
> https://raw.github.com/lutter/deltacloud/tracker/design/site/content/tracker.mdown

And the pretty version is at
http://people.apache.org/~lutter/deltacloud/tracker.html

> > The resource changes that will trigger a notification to clients are
> > specific to each resource (and driver ?) They are
> >
> > * Instances: change to instance state
> > * [TODO: what else ?]
> 
> Realms are needed too. We check realms availability in Conductor, so we 
> will not be able to replace our current checking tool with Tracker until 
> realms are supported too.

Realms is something that gets measured indirectly, right ? I.e., realm
availability is based on success/failure of launching/running instances
in that realm.

> > and to delete a callback, use the special token 'none':
> >
> >     PUT /instances/42?track_hook=none
> >
> 
> Authentication will be needed for ^ these requests to make sure that 3rd 
> party doesn't modifies my callback.

The tacit assumption in the whole writeup is that all operations require
the backend auth credentials, like other DC requests; so to
delete/modify a hook, you'd have to prove that you can modify the
underlying resource.

> > To make it possible for recipients to catch up after a failure on their
> > side, we'll support a 'changes' collection that only allows GET:
> >
> >     GET /changes
> >
> > The response to this request will be a JSON array, where each entry is the
> > same JSON object that is used for delivering callbacks. Note that only
> > changes pertinent to the current provider will be delivered, i.e. clients
> > that use Tracker to track resources in multiple providers will need to make
> > one request for each provider. Once a change has been delivered through
> > this mechanism, it will be considered successfully delivered.
> >
> 
> This might be a problem if Tracker is used by multiple clients - _all_ 
> callbacks for a provider are fetched by one request no matter whom these 
> callbacks are addressed to.
> 
> Maybe 'GET /changes' could just trigger common retry of callback 
> delivery for all provider requests instead of returning changes 
> directly. Another benefit is that then 'GET /changes' wouldn't have to 
> be authenticated.

Same as above: the assumption is that they are implicitly scoped by
backend account.

> > # Implementation Notes
> >
> > We will need to run a background job that performs the state
> > polling. DelayedJob seems like the right tool for this; we'll want a
> 
> +1 for delayed job - we already have this requirement in conductor

What we need is slightly different from what delayed job gives you: we
need cron-like functionality to run tasks at fixed intervals, whereas
delayed job is used for handling one-shot tasks in the background. It's
possible to use delayed job for this, but hopefully somebody else has
come up with something that is closer. (Haven't looked yet)

David





More information about the aeolus-devel mailing list