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
>
>
> On Mon, Nov 29, 2010 at 2:11 PM, Andy Edmonds <andy.edmonds@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@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.
> >
> >