17 Apr
2009
17 Apr
'09
12:27 p.m.
Quoting [Sam Johnston] (Apr 17 2009): > > On Fri, Apr 17, 2009 at 1:18 PM, Edmonds, AndrewX > <[1]andrewx.edmonds@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@elastichosts.com] > Sent: 17 April 2009 12:06 > To: Sam Johnston > Cc: Edmonds, AndrewX; Andre Merzky; [3]occi-wg@ogf.org > Subject: Re: Nouns and Verbs (was: Syntax of OCCI API) > Sam Johnston <[4]samj@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@intel.com > 2. mailto:chris.webb@elastichosts.com > 3. mailto:occi-wg@ogf.org > 4. mailto:samj@samj.net -- Nothing is ever easy.