cloud state requirements

Michal Fojtik mfojtik at redhat.com
Wed May 23 10:58:08 UTC 2012


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.

> 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

For this we will need to know following:

1. The time interval that we will use for checking.
2. The 'protocol' we will use to deliver something when a change occurs

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

That is a very nice idea however we will need to think about that more:

1. What will happen with the hook itself when it deliver results.
2. What will be reported if a failure occurs on backend side while pooling.
3. How we will deal internally with 'too much requests' to backend API (EC2
   has some unknown limits, etc...) (FIFO?)

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

> TODO: how to handle hook failures (conductor is not accessible and hook
> can't be invoked)?

The question is related to my 1. question. If hook fail to deliver results
if we gonna store it (eventlog) or we just remove the hook...

> TODO: how to handle credentials? will the stateful app keep credentails
> permanently for each instance being checked?

I'm afraid we will need to keep them together with the 'hook' (in a
database?)

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

Sounds reasonable.

  -- Michal

-- 
Michal Fojtik
Sr. Software Engineer, Deltacloud API (http://deltacloud.org)



More information about the aeolus-devel mailing list