On 04/11/2012 11:02 AM, Eoghan Glynn wrote:
* Inconsistent with other flows. We do not normally update status fields to perform actions. For example to run a VM, we do not update it's status to 'activated', we run an action (start).
I think this point is the crux of the matter.
IMO the consistency between activation implemented as direct state manipulation versus the state change occurring as a side-effect of an action, would be a deal-breaker.
IIRC one of the reasons we avoided that kind of direct state manipulation first time round is that it doesn't lend itself to multi-state transitions, e.g. activation that traversed multiple intermediate states, say:
quiescent->pending->activating->activated
That example is a bit contrived and unrealistic, but in any case the principal is that the client-visible state machine for a resource may not necessarily transition directly from the initial to the terminal state.
Exactly. The target state is not always indicative of the exact state transition path. A simpler example is "power off" vs "shutdown". Both end up with a VM in the "down" state, but the two are actually quite different.
Also an action as opposed to a direct state manipulation makes it more natural to express side-effects of the activation, and to implement in-progress status querying or cancelation.
For those reasons, I'm thinking that using actions consistently accross the board is better than exposing an action in one case while allowing a direct state manipulation in another.
So my vote would be for option #2.
One question though (probably to Ori): from the API that you propose, i assume that disk hotplug is implemented as a two stage process in the backend? - add the disk to a VM - activate it Because if it's just a one stage process then that would change things. Then you'd probably want to activate it directly as part of the POST call that adds the disk. As an action name i think "hotplug" and "unplug" are slightly more descriptive of what you actually mean. So my vote would go for those names instead. Regards, Geert