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

[Edmonds, AndrewX]

Ah! As always the devilish details! :-)

Such important nuances, I believe, can be supported via attribute (just a parameter) of the verb:

e.g. stop (GRACEFUL) or stop(KILL)
where the parameters wrt the stop verb are defined by a restriction/enumeration. This too supports the restart verb (b).

> (a) What state is a server in when it is created?
Well won't the result of a POST to server/create utilise HATEOAS or something similar? The result should contain information pertaining to the state of the resultant action.

Andy

-----Original Message-----
From: Chris Webb [mailto:chris.webb at elastichosts.com]
Sent: 17 April 2009 12:06
To: Sam Johnston
Cc: Edmonds, AndrewX; Andre Merzky; occi-wg at ogf.org
Subject: Re: Nouns and Verbs (was: Syntax of OCCI API)

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


(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 ]
  start
  kill
  shutdown
  suspend
  reset

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.

Cheers,

Chris.
-------------------------------------------------------------
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.