[occi-wg] OCCI Specification draft -Storage

[Gary Mazz]

Hi Richard

Comments inline

Richard Davies wrote:
> 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.
>   
Agreed, I have asked for a place for provisioned resources not attached 
to a compute resource. This is important in cases where occi is only an 
interface for interchange and other provider specific interfaces will be 
used to provision resources, including automated policies provisioning 
resources on customer signup.
>   
>> 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.
>   
Ok got it. There is a class of storage that is tied directly to the 
on/off state of the VM.

> Cheers,
>
> Richard.
>
>