[occi-wg] OCCI Specification draft -Storage

[Gary Mazz]

Hi Richard,

Thanks for the comments, they are welcomed and appreciated.

I'd like like to address some of your comments and changes to the 
storage attributes that were partially reviewed but not approved on last 
Wednesday's meeting.

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. 

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.  


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. 

Does this meet your requirement or am I misinterpreting your request ?

BTW, The OCCI spec has still not reconciled maintaining a list of provisioned resources that are not associated with a compute resource. 


Cheers,

gary



Richard Davies wrote:
> I was on Wednesday's call, but here are the points that I made written out
> as well.
>
> They are mostly the same as I made on 18th August in my post
> http://www.ogf.org/pipermail/occi-wg/2009-August/001113.html
> There was some discussion at that point, but not much seems to have been
> integrated.
>
>
>
> Page 4-5, paragraphs 13-24
> Page 8, paragraph 29
>
> We define 3 OCCI formats in page 12, paragraph 61: text/occi,
> application/occi+atom, application/occi+json.
>
> 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).
>
>
>
> Page 8, paragraph 43
> Page 18, paragraph 78
>
> I can't find any actual actions listed anywhere in this document. Are they
> defined yet? We need things like stop and start for servers, etc. as
> discussed when we used to call these verbs in a state machine.
>
>
>
> Page 10, paragraph 52
>
> "Where an operation returns multiple resources ..." to be replaced with
> "Where an operation COULD return multiple resources..."
>
> to make it clear that a collection is always returned, even if there is a
> single result.
>
>
>
> Page 10, paragraph 56-57
> Page 18, paragraph 79
>
> I'd like to see a more detail in one of these places on specifying the
> details of a link between compute and network - e.g. which interface does
> the network appear on (eth0, eth1, etc?), which static IPs are available to
> a customer and which will be used on this interface?
>
> Will we specify canonical interface names for OCCI or allow each cloud to
> chose its own (eth0 vs. Local Area Network, etc.)?
>
>
>
> Page 10, paragraph 56-57
> Page 18, paragraph 80
>
> Similarly, I'd like to see more detail in one of these places on specifying
> the details of a link between compute and storage - e.g. which interface
> does the storage appear on (sda, sda, etc?), which of multiple storage
> resources is the boot device?
>
> Will we specify canonical interface names for OCCI or allow each cloud to
> chose its own (sda vs hda vs C:, etc.)?
>
>
>
> Page 17, paragraph 76
>
> In my use cases, I don't see much value for raw hostnames of network or
> storage resources. Perhaps make this optional or for compute only? Or
> perhaps generalize it from just a hostname to a full URL - I can imagine
> having some kind of web interface for directly accessing a network or
> storage resource?
>
>
>
> Page 18, paragraph 78
> Page 19, paragraph 80
>
> 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.
> - Compute: add a 'compute.type'? which is Enum(transient, persistent).
>
> - Storage: add a 'status' which is 'mounted', 'inactive', etc.
> - 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
>
>
>
> Page 19, table 7
>
> 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. To take Gary's suggestion of supporting SI
> suffixes.
>
>
>
> Page 18, paragraph 78
> Page 19, paragraph 80
>
> I definitely feel that the compute.memory.speed, compute.memory.reliability
> and storage.reliability are less important than the other attributes
> described.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>