On 21/11/12 13:40, Michal Fojtik wrote:
On Nov 20, 2012, at 4:54 PM, Tomas Sedovic <tsedovic(a)redhat.com> wrote:
> Good news everyone!
>
> During our discussions about the Aeolus API at the first Technical Cabal meeting,
Michal Fojtik suggested we look at the CIMI spec (which Deltacloud partially implements).
>
> Apparently, it tackles a lot of things we are or will be discussing here, too. Things
such as state changes, multi-instance deployments, networking, etc.
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?
marios
Having all these three components working together will result in
full CIMI
stack :-)
-- Michal
>
> You can download it from the DMTF website:
>
>
http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.1.pdf
>
> It's a *massive* document (178 pages, ffs) but I think it may be worth checking
it out.
>
> Thomas
Michal Fojtik
http://deltacloud.org
mfojtik(a)redhat.com