- 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.