Hi Gary, Sorry for the time getting back. Some answers...
RD: - Storage: add a 'status' which is 'mounted', 'inactive', etc.
GM: Storage Status has been added to the attributes. Status is define as an enumeration using terminology consistent with the storage industry. Status values currently selected include Online, Offline, Standby and Degraded. These status values reflect the disposition of the raw virtual storage device.
Yes, and this is fine.
GM: Your comments reflect another type of status that pertains to the operating system's disposition to the storage ie mounted and unmounted. I believe supporting this class of status qualifies as a step into PAAS space and significantly increases the complexity of OCCI implementations. Supporting the mounted and unmounted status values requires integration into the operating system's file system operating modes which may require additional monitoring and management technologies for each OS supported.
I actually meant one step back from that - 'attached to a compute resource' and 'not attached to a compute resource', regardless of whether the compute resource's operating system is actually mounting the drive. I think this is still IaaS. It's useful too - for example ElasticHosts API exposes this and we use it to prevent users attaching the same storage to multiple compute resources and accidentally corrupting their filesystems.
RD: - Storage: reliability isn't the same as transient/persistent. A persistent RD: storage is one which isn't destroyed when the compute shuts down. It could RD: still be on RAID, local disk, SAN, etc. So split out 'storage.type'? which RD: is Enum(transient, persistent) from storage.reliability
GM: Agreed, reliability isn't the same as durability or retention duration. I believe there is a little confusion about the compute life cycle, and the relationships and provisioning status of resources. In OCCI, storage and networking resources are bound to a compute resource. The compute resource life cycle can be describe in 3 basic abstract states, existing, not existing and operating. In the existing state, we a have a configuration provisioned and coordinated in the provider infrastructure. The nonexisting state defines relationships between resources and any provisioning as invalid. The operating state where the VM can be on, off, paused, etc. In the OCCI model, even though the compute resource is "off" it still exists and all associated resources remain provisioned. If the end user would like the storage deleted immediately after the compute resource is switch off, it may be manually deleted, if that's permissible by the provider.
The retention duration attribute defines the time a storage resource will be around "after" the deletion operation is requested by the end user. The user may request the storage is kept for a while or deleted immediately.
Yes, you are broadly correct. I am only really considering two options here: deleted immediately or left around indefinitely. We see two very different behaviours on existing clouds when an compute's operating system is shut down internally (i.e. by a user logged into that compute resource, without any API calls being made). Amazon: When the compute's operating system shuts down, the compute and the storage are immediately gone for ever. GoGrid: When the compute's operating system shuts down, the compute and the storage both remain available to be restarted later. OCCI should support both, and should do so by having a property on both compute and storage resources which specifies what will happen to them when the compute resource shuts down. Cheers, Richard.