On Wed, Nov 21, 2012 at 02:22:48PM +0100, Michal Fojtik wrote:
On 11/21/2012 01:39 PM, marios(a)redhat.com wrote:
>>Call me crazy, but this what I was thinking about:
>>
>>* Deltacloud CIMI to provide low-level API (Machine, MachineConfig, etc)
>>* Aeolus API to provide high-level (n-tier, System, SystemTemplate)
>>* Heat API to provider monitoring, event CIMI stuff.
>
>I like the sound of that! There is a natural alignment there with the
>current status quo - Deltacloud for stateless management of resources,
>stateful Conductor one level up allowing organisation of those resources
>into aggregations.
>
>This would solve the (current Deltacloud) problem "we can't support
>systems if the back-end cloud doesn't" - Conductor can create 'pseudo
>systems'.
>
>One issue is it will be messy to have this "CIMI stack" spread across
>components; I mean would you need to use 3 different APIs and talk to 3
>different services? Is it possible to have a single unifying 'Aeolus
>API' giving access to all?
As DC is Rack mountable, it will be easy to just mount it into Conductor :-)
Other components, like Heat can be proxyfied using nginx/httpd :)
This is starting to sound very, very interesting to me.
If we wanted to attack this aggressively, where would we start? And,
would we want the Aeolus API to be a separate standalone beast that
would be smart about delegating to the correct components, or would we
want separate bits of Aeolus to implement separate chunks of the API?
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
==
http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey