[occi-wg] OCCI specification document

[Gary Mazz]

Hi,

I think many of Richard's comments is a result of the API document 
lagging consensus reached in the weekly conference calls.

Below is a list of Richard's comments already addressed, but not in the 
OCCI API document.

5. Nouns and attributes -  On the topic of units MB,GB, TB, we had 
agreed on IEC 60027-2 as the unit of measure for values. This standard 
permits the use of kilo, mega, giga, etc... Requiring the support of a 
float type in this case, for CD images less then GB capacity,  is 
unnecessary .

Status and reporting: Richard brings up a good point. The status values 
are not clearly defined, in terms of life cycle state.

Storage stuff:

Richard again brings up a good point about storage durability. Its a 
broad class of service quality not a specific technology. Defining a 
durability definition for storage was touched on but, do not believe 
solid consensus was not reached. I'd like to add this as a discussion 
item for tomorrow's conference call.

The fact that storage is RAID or mirrored, retention periods or if data 
is "shredded" after use should be considered part of a "back office" 
infrastructure and out of scope for this version of OCCI. However, I 
think this is the perfect opportunity take advantage of OCCI "linking" 
to SNIA's CDMI. 

-gary

Mark A. Carlson wrote:
>
>
> 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
> ------------------------------------------------------------------------
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>