[occi-wg] Nouns and Verbs (was: Syntax of OCCI API)
Edmonds, AndrewX
andrewx.edmonds at intel.com
Fri Apr 17 07:49:45 CDT 2009
Good question! OVF has a software lifecycle [1] that begins at package/distribute and moves to a deploy phase. I feel we can insert and relate many of our ideas after the OVF-deploy phase, which is Manage.
Andy
[1] page 2 of http://www.dmtf.org/initiatives/vman_initiative/OVF_Tech_Note_Digital.pdf
-----Original Message-----
From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Alexis Richardson
Sent: 17 April 2009 13:32
To: Andre Merzky
Cc: occi-wg at ogf.org
Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API)
+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
>
_______________________________________________
occi-wg mailing list
occi-wg at ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg
-------------------------------------------------------------
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.
More information about the occi-wg
mailing list