[occi-wg] OCCI Specification draft -Storage

[Richard Davies]

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.