deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Provaznik <jprov...@redhat.com>
Subject Re: Deltacloud Tracker Design (Draft)
Date Mon, 11 Jun 2012 09:16:57 GMT
On 06/08/2012 02:30 PM, David Lutterkort wrote:
>>>>> 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).
>
> How do you check ?
>

Checking is now done by a ruby script 
(https://github.com/aeolusproject/conductor/blob/master/src/dbomatic/dbomatic) 
which fetches realms for each provider account every 5 minutes. The list 
of fetched realms is then compared with realms in Conductor's DB - 
availability status is updated, realms missing in DB are added, realms 
which are in DB but not on the fetched list are removed.

We keep availability flag also for whole providers: if fetching of 
realms for a provider account fails because of a connection error, whole 
provider is marked as unavailable and skipped on instance launch.

Jan

Mime
View raw message