[occi-wg] Nouns and Verbs (was: Syntax of OCCI API)
Sam Johnston
samj at samj.net
Fri Apr 17 08:13:05 CDT 2009
I've been working from a dead tree version which I'll convert to SVG asap.
Sam
On Fri, Apr 17, 2009 at 2:49 PM, Edmonds, AndrewX <andrewx.edmonds at intel.com
> wrote:
> 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.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090417/15907e50/attachment.html
More information about the occi-wg
mailing list