[ Adding dev@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
