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). It's conceivable that some implementations would want to support both (where ephemeral storage might be faster and/or cheaper than more reliable alternatives).
This is a pet peeve of mine, so I would be willing to do it. I added a
VMware column, but I don't feel comfortable adding rows unless there
is some consensus on what they should be. VMware has a lot of small
but IMO essential features that most clouds don't have (e.g. full
virtualization, shared block storage, thin provisioning, HA, VLANs,
reverse ARP, etc.) but it's not clear to me that we want the feature
matrix to get into that level of detail.
The feature matrix should be concise and readable but still carry enough information to be useful... I guess about 20 rows.
In terms of specific features:
- raw hardware vs para virt. vs full virt. vs containers vs emulation is useful/interesting (along with the specific container type for drivers etc).
- shared block storage (e.g. for clustering) is already possible with OCCI - just connect the same storage resource(s) to multiple compute resources
- thin provisioning is particularly interesting (if not essential) for public cloud providers (but may or may not be exposed to the user via attributes)
- some types of HA can be modeled already by linking compute resources together - I'm not sure how much more we want/need
- VLANs have already been mentioned and can be as simple as having an 802.1q attribute on the network resources
- RARP is more of an internal concern
My main concern is to make the API sufficiently extensible that its users can achieve a lot of this itself (because much of it falls outside of our initial scope).
Sam
Wes Felter - wesley@felter.org - http://felter.org/wesley/