[occi-wg] OCCI specification document

[Richard Davies]

Hi all,

Some brief comments after reading through the current (23 July) draft
specification.

Cheers,

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.


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


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.



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.