[occi-wg] Semantics of OCCI API: nouns and verbs

[Sam Johnston]

On Thu, Apr 16, 2009 at 2:29 PM, Andre Merzky <andre at merzky.net> wrote:

> > I'm not sure about rounding up as such - feels a bit messy
> > (exceed the limit by 1 byte and your cost will double for
> > example). If the provider has templates these should be
> > advertised but ultimately it's up to the implementor to
> > decide whether to reject a request for an unsupported
> > configuration with an error or whether to satisfy it
> > anyway with a larger device.
>
> I think you should not leave that to the implementor, really
> - there is a significant semantic uncertainty in the API
> when you leave 'minimal resource requirements' versus
> 'exact resource requirements' unspecified.
>
> Exact requirements avoid the pricing pitfalls you mention.
> Minimal requirements are more flexible, and probably more
> interoperable.
>
> As I assume the user has to control pricing out of bound
> (i.e. outside of this API) anyway, I'd vote for the minimal
> spec approach.
>
> My $0.02, Andre.


Hmm... I'm not sure... if you look at Amazon EC2's pricing you'll see that
if you crack the limit on a standard small instance you'll be silently
bumped from 10c/hr to 40c/hr (that is, from $72 per instance per month to
$288 per instance per month).

I for one would have a problem with being hit with a bill 4x bigger than
what I expect, especially given the provider would be free to move the
cutoff points up and down as they see fit.

In fact I see little point in retrieving the specs of a "template" only to
send them back verbatim to request one... I'd suggest instead that these be
cloned (e.g by GETting http://example.com/<id>/ops/clone). That's keeping
the bar low for simple clients and neatly sidestepping the problem.

It's always going to be more complex to specify custom configurations
(though perhaps even these linear offerings will offer sensible templates
for cloning while allowing subsequent tweaking of values), so I don't think
it would hurt to do both. If a provider wants to accept "fluid" allocations
and silently upsize their clients' requests then there's nothing technically
stopping them from doing so...

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090416/dad8ee00/attachment.html