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

[Andre Merzky]

Quoting [Sam Johnston] (Apr 17 2009):
> 
>    On Fri, Apr 17, 2009 at 1:18 PM, Edmonds, AndrewX
>    <[1]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.

A client can always map from a complex API to a simple
(G)UI.  It should not be problem to have a single STOP
button, and when pressing that to perform a couple of API
calls with more diverse semantics?


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

BTW: we should start to draft a state model...

Oh well, I don't have a candidate, really, but here is food
for discussion:

  New --> Running  --> Stopped

  Running <--> Suspended
  Running <--> Migrating

Andre.


>    Sam
> 
>    -----Original Message-----
>    From: Chris Webb [mailto:[2]chris.webb at elastichosts.com]
>    Sent: 17 April 2009 12:06
>    To: Sam Johnston
>    Cc: Edmonds, AndrewX; Andre Merzky; [3]occi-wg at ogf.org
>    Subject: Re: Nouns and Verbs (was: Syntax of OCCI API)
>    Sam Johnston <[4]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.
> 
> References
> 
>    1. mailto:andrewx.edmonds at intel.com
>    2. mailto:chris.webb at elastichosts.com
>    3. mailto:occi-wg at ogf.org
>    4. mailto:samj at samj.net



-- 
Nothing is ever easy.