deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Provaznik <jprov...@redhat.com>
Subject cloud state requirements
Date Wed, 23 May 2012 07:13:40 GMT
Hi,
Deltacloud is going to implement a stateful app on top of DC API. This 
app will do very similar job to what we planned with Cloud State. Some 
basic ideas/thoughts about Cloud State are described on wiki:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Cloud_State

So for us it would be much easier to use this deltacloud app instead of 
implementing the same thing.

Here are some basic requirements which we would need on Conductor side 
from the stateful app:
1) the app should check state of not only instances but also other 
resources - we need especially realms because we check availability status

2) it should be possible to register hooks for a resource I want to 
watch, hook could be just an URL, when the resource is changed data are 
POSTed to the registered URL.
TODO: authentication when posting data to hook url? we use oauth between 
other components now
TODO: how to handle hook failures (conductor is not accessible and hook 
can't be invoked)?
TODO: how to handle credentials? will the stateful app keep credentails 
permanently for each instance being checked?

3) frequency of instance status checking: we probably don't need to have 
this configurable, but the checking frequency should be as low as 
possible - various actions are hooked to instance state changes (for 
example runtime is measured by this). It should be also scalable - if 
there are 100 instances for one provider account, we still need check 
all of them. Would be nice to use multiple parallel requests to provider 
if possible or checking interval might be dynamically increased 
according to the actual length of queue).

Jan

Mime
View raw message