[occi-wg] Finished first pass over FeatureMatrix

[Sam Johnston]

Hi Wes,

Thanks for your contributions - it's good to have you on board.

On Mon, Jun 15, 2009 at 12:20 AM, Wes Felter <wesley at felter.org> wrote:

> 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 at felter.org - http://felter.org/wesley/
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090615/5b1d1a82/attachment.html