[occi-wg] Finished first pass over FeatureMatrix

[Richard Davies]

> > A cloud that supports persistent resources can easily emulate
> > ephemeral resources (just stop and immediately destroy the resource),
> > so should we give the persistent clouds credit for this "feature"?
> 
> We're assessing the APIs themselves rather than the underlying
> implementations - which is to say that such features should be natively
> (or at least sensibly) supported. Users shouldn't get nasty surprises like
> finding that pressing "stop" on a compute resource results in various
> storage resources being implicitly destroyed (rather ephemeral storage
> should be specified at boot or at least exposed in the attributes).

Absolutely - as Sam say the behaviour is very different when the server
shuts down (persistent servers -> stopped state, ephemeral servers -> gone;
persistent storage -> stays, ephemeral storage -> gone).

So users of the OCCI API need an attribute or some such on servers and
storage so that they can explicitly request ephemeral or persistent.

> It's conceivable that some implementations would want to support both
> (where ephemeral storage might be faster and/or cheaper than more
> reliable alternatives)

There's a strong argument for clouds to support both. Persistent storage is
typically on SAN where it can be accessed from all virtualization hosts when
the server is stopped and restarted. Ephemeral storage is typically on local
disk, which is much faster but unavailable after the server is stopped and
restarted on a different machine.

This is most obvious in Amazon AMIs vs. EBS. Other providers hide it a bit
better!

Cheers,

Richard.