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.