[occi-wg] OCCI specification document

[Thijs Metsch]

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..

> For networks, I feel there's missing content:
> 
> - There is no mechanism described for static IPs on the public internet
> - The network.ipv4 is almost enough to run a DHCP server, but not quite.
>   You'd really need name servers too.
> 
> 
> What is the hostname attribute in table 7? Is this just an example? I don't
> really see it as a common attribute, so that networks and storage have a
> hostname...
> 
> 
> I definitely feel that the compute.memory.speed, compute.memory.reliability
> and storage.reliability are less important than the other attributes
> described.

How would you like to handle this? Add a column to the table and stating
the severity?

> 4.4.3 Links
> 
> I'd like to see a little more detail here on how I specify the interface by
> which compute is linked to storage or network. (e.g. eth0, eth1, sda, sdb,
> etc).
> 
> Presumably this will end up in the link[i].rel field?
> 
> Will we specify canonical interface names for OCCI or allow each cloud to
> chose its own (eth0 vs. Local Area Network, sda vs hda, etc.)?
> 
> How will a compute resource specify which of many linked storage resources
> it should boot from?
> 
> 
> 
> 4.2 Collections
> 
> "Operations that return multiple resources are rendered ..."
> 
> shall we write "Operations which COULD return multiple resources..."
> 
> to make it clear that Atom is always returned, even if there is a single
> result?
> 
> Or should we explicitly say that single results are NOT returned as Atom.
> _______________________________________________
> 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