[occi-wg] OCCI Specification draft

[Richard Davies]

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.