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

[Sam Johnston]

On Fri, Apr 17, 2009 at 1:18 PM, Edmonds, AndrewX <andrewx.edmonds at intel.com
> wrote:

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

So a client should probably know where to find basic buttons like "start"
and "stop" without having to know all the permutations (including others yet
to be invented relating to live migrations and the like). Parameters are one
way to implement this but they increase complexity... maybe just "stop" for
the most sensible approach for the given infrastructure (ranging from
pinging a daemon to ask for a graceful shutdown) to yanking the cord for
physical servers, and "stop/graceful" etc. for more nuanced versions.

Let's flesh out the options first...

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


Agreed, most actions should return [pointers to] resources and from there
you can tell whether you're "stopped", "starting" or "started" and you'll
know what transitions are available to you.

Sam

-----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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090417/28883035/attachment.html