17 Apr
2009
17 Apr
'09
1:13 p.m.
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@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf > Of Alexis Richardson > Sent: 17 April 2009 13:32 > To: Andre Merzky > Cc: occi-wg@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@merzky.net> wrote: > > > > 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. > > _______________________________________________ > > occi-wg mailing list > > occi-wg@ogf.org > > http://www.ogf.org/mailman/listinfo/occi-wg > > > _______________________________________________ > occi-wg mailing list > occi-wg@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@ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg >