[occi-wg] OCCI specification document

[Richard Davies]

> > - Storage: reliability isn't the same as transient/persistent. A persistent
> >   storage is one which isn't destroyed when the compute shuts down. It could
> >   still be on RAID, local disk, SAN, etc. So split out 'storage.type'? which
> >   is Enum(transient, persistent) from storage.reliability
> 
> We probably should ping the guys from SNIA about this one. I cced Mark..

Mark,

To explain my point further, I'm trying to differentiate between two
different semantic behaviours for cloud storage.

Taking Amazon as an example:

- The root filesystem (AMI image) is 'transient': when each a server starts,
  a clean root filesystem is created and a clean copy of the AMI image is
  installed. This is all deleted when the server exits.

- Elastic Block Store (EBS) volumes are 'persistent'. These can be mounted
  from a server after it starts. They continue to exist when that server
  exits and can later be mounted by a different server.


These are different semantic behaviours, which say nothing about the
underlying storage reliability (whether it is local disk, RAIDed local disk,
SAN, regularly backed up to tape, etc).

Nevertheless, this 'storage type' does need to be specified on an OCCI
storage resource, since it will behave differently when a server exits, and
some cloud providers can provide both options.

I suggest two separate attributes: storage.type for transient/persistent
behaviour and storage.reliability for the nature of the underlying hardware.


Similarly, OCCI compute resources will need a type of 'persistent' or
'transient'. Transient resources vanish when the server exits (like Amazon
instances), whereas persistent resources become 'stopped servers' (like
GoGrid).

Similarly, some cloud providers will offer both types of compute resource
(e.g. persistent for servers which are expected to run 24/7 except for brief
periods shut down for maintenance, vs. transient for burst compute uses).


Cheers,

Richard.