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

[Alexis Richardson]

+1 to state model for lifecycle.  In my experience having one makes a
compelling improvement to the plausibility and understandability of a
protocol.

Q: should the lifecycle have a relationship with OVF lifecycle?


On Fri, Apr 17, 2009 at 1:27 PM, Andre Merzky <andre at merzky.net> wrote:
>
> 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.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>