deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject Re: cloud state requirements
Date Thu, 24 May 2012 00:42:08 GMT
On Wed, 2012-05-23 at 12:58 +0200, Michal Fojtik wrote:
> On 05/23/12, Jan Provaznik wrote:
> > 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.
> 
> We're going to implement this as part of the 'demoware' stuff we planed.
> I'm not sure how deep we want to go with this in terms of architecture, but
> I hope it will help you guys somehow. My plan is to make this 'app'
> Sinatra::Base so will be eventually able to use it and extend it as you
> will need.

I think if we hook this in at the drive level, we'll immediately get the
benefit of multiple frontends for this, so that users can talk to their
state tracker using DC, CIMI, or (eventually) EC2. Most of the state
tracker should be transparent to the user.

> 3. How we will deal internally with 'too much requests' to backend API (EC2
>    has some unknown limits, etc...) (FIFO?)

We will need to have a background job (DelayedJob ?) in any event;
failures like 'too many requests' should just lead to a transient
failure of that tracking effort, and get picked up the next time around.
It shouldn't make it to the user of the state tracker.

> > TODO: authentication when posting data to hook url? we use oauth between
> > other components now
> 
> You will need to send API_KEY/API_SECRET keypair as ussual. My personal
> opinion is to stay with Basic HTTP auth as we have now ;-)

For the classic DC API, I am thinking this will mostly be the existing
API, with a 'state-tracking' feature for create_instance, which allows
registering a hook for that instance. Similar for other kinds of
resources.

In addition, we'll want a 'events' collection (global), and a 'hooks'
collection (not sure of we need global, or just embedded in each
resource) so you can register hooks after resource creation.

David



Mime
View raw message