deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Provazník <>
Subject Re: Deltacloud Tracker Design (Draft)
Date Fri, 08 Jun 2012 11:12:06 GMT
On 06/08/2012 12:31 PM, David Lutterkort wrote:
> [ 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:
> And the pretty version is at
>>> 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.

No, we check periodically realm's availability (unavailable realms are 
then ignored when launching an instance).

>>> 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)

True, we were choosing some tool for this purpose on Aeolus side too few 
weeks/months ago (before we knew about Tracker). Richard Su made lot of 
work in this area (CCing him) so it would worh discuss this with him, 
wiki page with related stuff is here:

mail thread is here:

> David

View raw message