On Wed, Nov 21, 2012 at 02:22:48PM +0100, Michal Fojtik wrote: > On 11/21/2012 01:39 PM, [email protected] 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, [email protected] == == 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
