[occi-wg] OCCI specification document

[Mark A. Carlson]

Thijs Metsch wrote:
> Hi Richard,
>
> Thanks for your comments...added some inline questions/comments/ideas
> etc...
>
> @Mark do you have any ideas/suggestions regarding the storage related
> comments from Richard?
>
>   
>> 2.3 Operations
>>
>> As described, Create is form-encoded, Retrieve is in application/occi+X,
>> Update is in application/occi+X, Delete doesn't need a format, and Requests
>> are form-encoded.
>>
>> I'd like us to also support application/occi+X for Create and Requests so
>> that it's possible to write a client which only knows about a single format
>> rather than having to implement at least two (form + one occi+X).
>>     
>
>   
>> 5. Nouns and attributes
>>
>> You'll need to make storage.size a Float, like compute.memory.size to allow
>> drives below 1 GB (e.g. CD images). Alternatively (and better in my view),
>> you could turn all of Floats into integers and describe them in the basic
>> units - bytes, hertz, etc.
>>     
>
> good remark with regards to the CD images!
>
>   
>> Compute and storage resources need better status and support for being
>> transient or persistent (a cloud could support both models, so needs to be
>> told which a given resource will be, since the semantics are different when
>> a server shuts down). I'd suggest:
>>
>> - Compute: add a 'status', which is 'active', 'stopped', etc. (maybe 5.2.1
>>   state machine handles this? But the section is empty).
>> - Compute: add a 'compute.type'? which is Enum(transient, persistent).
>>
>> - Storage: add a 'status' which is 'mounted', 'inactive', etc. (again, does
>>   5.2.1 handle this?)
>> - 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..
>
>   
I think you are talking about something beyond what the "storage" does. 
This is more the VMM infrastructure reuse or
non-reuse of storage given to it. Thus it should be exposed by OCCI, but 
CDMI has no notion of it.

CDMI will have the ability to "shred" the data on storage that is freed 
by the infrastructure, however. So when a guest is done,
the data may be truly destroyed.

-- mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090818/5026c8d8/attachment.html