[occi-wg] OCCI Specification draft

[Thijs Metsch]

Thanks Richard! I'll put all of your comments in the issue tracker as
well!

Cheers,

-Thijs


On Wed, 2009-09-23 at 17:03 +0100, 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
-- 
Thijs Metsch                        Tel: +49 (0)941 3075-122 (x60122)
http://blogs.sun.com/intheclouds
http://www.twitter.com/befreax
Software Engineer Cloud, Grid and Virtualization
Sun Microsystems GmbH
Dr.-Leo-Ritter-Str. 7               mailto:thijs.metsch at sun.com
D-93049 Regensburg                  http://www.sun.com