Below is some feedback received from vmware (thanks Mark) on the specifications... Andy andy.edmonds.be ---------- Forwarded message ---------- From: Mark Pollack <mpollack@vmware.com> Date: Mon, Nov 29, 2010 at 15:08 Subject: RE: OCCI feedback To: Alexis Richardson <alexis@rabbitmq.com>, Andy Edmonds < andy.edmonds@gmail.com> Cc: Thijs Metsch <tmetsch@platform.com>, Adrian Colyer <acolyer@vmware.com> Hi, Linking off to another spec, with another metamodel, seems overly complex and quite a high barrier for adoption. I only happened to pick storage by accident as an example, is the same going to hold true for networking or other areas - handing off to other specs via links? I didn't really dive deep into the provisioning aspects of CDMI, I was looking at it more from the development perspective. I remember that the provisioning part was a surprise to most on the call at the time. Is discovering services at runtime practically useful? Dusty images of discovering CORBA services that never got used in reality come to mind - and if they did get used it was a rather up front prescriptive usage vs. dynamic discovery magic. I'll try to send this to the ML... if not, feel free to forward. Mark
-----Original Message----- From: alexis.richardson@gmail.com [mailto:alexis.richardson@gmail.com] On Behalf Of Alexis Richardson Sent: Monday, November 29, 2010 9:53 AM To: Andy Edmonds Cc: Thijs Metsch; Mark Pollack; Adrian Colyer Subject: Re: OCCI feedback
Mark
Please see below. Andy is co-chair and implementing OCCI at Intel.
alexis
Very fair comment especially in the area of moving up a stack wrt abstraction. With regard to storage, there's little point in developing, imo, a deep specification here given our (OGF-SNIA) agreements towards CDMI. It's for this reason that it would appear to be somewhat anaemic, If one wants something more extensive in the area of cloud storage management than what is offered by OCCI then CDMI is the recommended route. Our linking mechanism in OCCI will easily support this. On aspects of interoperability, what is expected of a provider is specified, however provider specific extensions can be discovered at runtime
the query interface. What we do want are provider-specific extensions
On Mon, Nov 29, 2010 at 2:11 PM, Andy Edmonds <andy.edmonds@gmail.com> wrote: through -
those that are common amongst a number of users are candidates for inclusion in the main OCCI specification set. Would your colleague be happy to submit such feedback to the group, whether be it through the ML, or public comment phase? Such feedback is important :-) Andy andy.edmonds.be
On Mon, Nov 29, 2010 at 13:52, Alexis Richardson <alexis@rabbitmq.com> wrote:
Andy, Thijs,
Some feedback on OCCI from a colleague -
a
I did a quick read through the spec docs. As it describes at a very basic level what one would want when provisioning infrastructure it runs the risk of specifying too little to be of any true portable value. Take storage for example. All that is required is to
specify
the size of disk and manipulate/query a state machine of its status. This seems too simplistic. Then everyone implementing this spec will come up with their own attribute extensions, thus removing any true portability. Of course there isn't a neat answer here, the problem itself just seems to lend itself only so far to common abstractions. Perhaps the target audience for this type of software doesn't care about those details as the problems one is solving treats the infrastructure as a pure transient commodity, e.g. run a big batch job for a day, vs. running a mission critical application 24/7.