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)