[occi-wg] Semantics of OCCI API: nouns and verbs

[Sam Johnston]

Chris,

Agreed re: "*The single strongest point we want to make is that an API
should be simple*", and the requirement for 15-20 operations. We currently
have somewhat less than that.

On Thu, Apr 16, 2009 at 11:32 AM, Chris Webb <chris.webb at elastichosts.com>wrote:

> Comparison with draft API on the wiki
> =====================================
>
> The draft API on the OCCI wiki currently appears to offer nouns for
> servers,
> storage devices, network interfaces with the ability to create, retrieve,
> update and delete any noun and 6 verbs for machine control.
>
> Our suggestion above is very similar, but more explicit and descriptive. In
> particular:
>
>  - list, info, create, destroy, set are equivalent to CRUD;
>

The CRUD operations map to HTTP verbs which were designed for making certain
actions on a resource - I don't see that there's a need to repeat ourselves
here by burning this information into the URL/request syntax. Quoting Tim
again from The Sun
Cloud<http://www.tbray.org/ongoing/When/200x/2009/03/16/Sun-Cloud>:
"*If you’re going to do bits-on-the-wire, Why not use
HTTP?<http://timothyfitz.wordpress.com/2009/02/12/why-http/>And if
you’re going to use HTTP, use it right.
*"

Non-CRUD operations such as start, stop, restart, clone, snapshot, etc. can
be exposed by "actuator" URLs, which fits nicely with HATEOAS.


> - added drive operations: read, write, image
>

I've deliberately steered clear of this for the minute while we reach out to
SNIA to see what they're up to in this area. Last thing we want is people
having to implement a second API for storage and/or overlapping too much
(but agreed we need to do some basic operations).


> - resize operation handled by passing the new size to drive set;
>

Sure, retrieving the object, tinkering with it and putting it back is the
best way to make such changes. I am not sold on the idea of changing
"running state" variables as a mechanism for managing stage machines - the
"push button" approach is cleaner and better for really simple clients.


> - nouns for network resources (e.g. static IPs, VLANs) rather than network
>    interfaces[1];
>

We have network resources (e.g. virtual networks) and machines can be linked
to any numer of networks (including none). Operations such as setting subnet
details, gateways, dhcp servers, etc. can be done by setting attributes on
the network resource (but these are rare - usually you just want to
instantiate a machine and connect it to storage and network resources).


> - similar set of machine operations, assuming we want to handle stopped
>    guests.
>

I think we'll be wanting to handle both persistent and ephemeral workloads.


> [1] We believe that interfaces are simply one aspect of a server's
> configuration, and that the nouns that matter are the objects such as
> static
> IPs which are "owned" by a customer and hence can be configured onto the
> server.
>

Interesting point - perhaps any static APIs available to that particular
user could be exposed in the network resource itself (along with an option
for DHCP if that is indeed an option).

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090416/bb2797a1/attachment.html