On Tue, Nov 20, 2012 at 04:54:51PM +0100, Tomas Sedovic 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. This looks interesting. I'd had only brief exposure to the concept prior to now, but some of the concepts it exposes do seem to line up well with what we do. Is Deltacloud still the only project implementing this in the wild? It seems interesting, but I'd hate for us to implement an API that few people end up using. (On the other hand, I suppose everyone else is probably saying this exact same thing right now...) > 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. Wait, you open with "Good news everyone!" and close with a link to a 178-page API specification? I'd hate to see your idea of *bad* news. ;) Seriously, though, this is interesting and seems like it's worth exploring further. (I can't say I've read the document in full yet.)

From: "Tomas Sedovic" <tsedovic(a)redhat.com&gt; To: aeolus-devel(a)lists.fedorahosted.org Sent: Wednesday, November 21, 2012 5:02:32 AM Subject: Re: Aeolus API and DMTF CIMI On 11/20/2012 10:50 PM, Matt Wagner wrote: > On Tue, Nov 20, 2012 at 04:54:51PM +0100, Tomas Sedovic wrote: >> Good news everyone! To quote Professor Farnsworth from Futurama: "Great news, everyone! You'll be delivering a package to Chapek 9, a world where humans are killed on sight."

On 20/11/12 23:50, Matt Wagner wrote: > On Tue, Nov 20, 2012 at 04:54:51PM +0100, Tomas Sedovic 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. > > This looks interesting. I'd had only brief exposure to the concept > prior to now, but some of the concepts it exposes do seem to line up > well with what we do. > > Is Deltacloud still the only project implementing this in the wild? It yes - we are aware (through our participation in dmtf cmwg) that there are others 'working on implementations' but we don't have anything more concrete than that. There is a plugfest being organised at the f2f meeting this December so we may learn more about other implementations there (David Lutterkort will be representing). > seems interesting, but I'd hate for us to implement an API that few > people end up using. (On the other hand, I suppose everyone else is > probably saying this exact same thing right now...) right... and there *are no guarantees* - however, if you look at the membership of the CMWG there is a serious industrial backing - Red Hat, Microsoft, IBM, Oracle, VMWare, Fujitsu, France Telecom, Telecom Italia, Telefonica and many others. I'd be surprised/disappointed if we don't see at least a few adopters amongst the people that made significant investments of time and effort to develop the spec.

> >> 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. > fwiw - I've been sitting on the DMTF weekly calls for 2+ years where we developed this spec. I don't know it by heart (!) but can definitely help and/or point you in the right direction if there are any questions, thanks, marios > Wait, you open with "Good news everyone!" and close with a link to a > 178-page API specification? I'd hate to see your idea of *bad* news. ;) > > Seriously, though, this is interesting and seems like it's worth > exploring further. (I can't say I've read the document in full yet.) > > -- Matt >

On Nov 20, 2012, at 4:54 PM, Tomas Sedovic <tsedovic(a)redhat.com&gt; 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.

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

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