[occi-wg] Nouns and Verbs (was: Syntax of OCCI API)

Chris Webb chris.webb at elastichosts.com
Fri Apr 17 06:05:53 CDT 2009

Sam Johnston <samj at samj.net> writes:

> Ok so nouns and verbs (ignoring CRUD which is common anyway):
> server:
>  - start
>  - stop
>  - restart
>  - deploy/undeploy? (comes back to persistent vs ephemeral etc.)
>  - clone/snapshot?

Tackling just this one first, there are two core semantic issues:

1. Ephemoral vs persistent servers

There will be providers that only have a concept of servers in the running
state (e.g. Amazon), providers with a concept of stopped/shutdown vms (e.g.
GoGrid) and clouds that want to implement both.

2. What's possible from outside in a virtualisation environment

We think the (complete?) list of user-visible 'things you can do to a vm'
are ACPI power button press, reset signal, kill the machine, pause the
machine and suspend/hibernate the vm to disk. Providers will implement some
subset of these, and of course machines can also reboot and
shutdown/power-off from within, independently of the API. These reflect on
the operations we can support, and how their behaviours can reasonably be

(a) What state is a server in when it is created? In Amazon's case, there's
only one state if the server exists---it's running. However, a more general
provider like GoGrid can have guests in a stopped state, and we might
reasonably want to be able to create them stopped, especially when
implementing a web interface. This means that if we want to support stopped
servers at all, we really need to be able to specify the desired initial
state of server when creating it, e.g.

  POST /server/create

  state stopped
  cpu 1000

(b) Whilst there is only really one meaning of 'start' and only one
(implementable) meaning of 'reset'/'restart', there are two varieties of
stop that we might want to expose: a graceful shutdown (which might be
implemented by an ACPI power-down event for example) and a hard kill of the
VM. Which sort of stop a 'destroy' does also needs to be specified. I think
there's also a hibernate or suspend operation that some providers might want
to export.

(c) What happens when a virtual machine powers-off from within? A provider
like Amazon has only one behaviour they can exhibit: shutdown = stop =
destroy. However, people who support persistent servers might want to yield
a server in a stopped state instead. To get predictable behaviour, there
probably needs to be a property of a server which indicates whether it's
supposed to persist or be one-shot.

Is the complete operation list perhaps something like

  [usual create / info / set / destroy ]

where destroy probably wants to be equivalent to a kill in effect, and with
a boolean 'persist' server property that determines when a server moves to a
stopped state or is deleted following a shutdown from the API or within.
(This can clearly only be false for people like Amazon.)

What did you have in mind for deploy and undeploy? I can see how they might
be identical to either start/stop or create/destroy, but I guess you intend
another meaning?

Let's discuss clone/snapshot later once we have some firmer ideas about the
core stuff.



More information about the occi-wg mailing list