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).
(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.
Andy -----Original Message----- From: Chris Webb [mailto:chris.webb@elastichosts.com] Sent: 17 April 2009 12:06 To: Sam Johnston Cc: Edmonds, AndrewX; Andre Merzky; occi-wg@ogf.org Subject: Re: Nouns and Verbs (was: Syntax of OCCI API) Sam Johnston <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.