[occi-wg] Fwd: OCCI feedback

[Andy Edmonds]

Below is some feedback received from vmware (thanks Mark) on the
specifications...

Andy
andy.edmonds.be


---------- Forwarded message ----------
From: Mark Pollack <mpollack at vmware.com>
Date: Mon, Nov 29, 2010 at 15:08
Subject: RE: OCCI feedback
To: Alexis Richardson <alexis at rabbitmq.com>, Andy Edmonds <
andy.edmonds at gmail.com>
Cc: Thijs Metsch <tmetsch at platform.com>, Adrian Colyer <acolyer at 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 at gmail.com [mailto:alexis.richardson at 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
>
>
> On Mon, Nov 29, 2010 at 2:11 PM, Andy Edmonds <andy.edmonds at gmail.com>
> wrote:
> > 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
> through
> > the query interface. What we do want are provider-specific extensions
> -
> > 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 at 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.
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20110110/e567b610/attachment.html