Petr: "Wow. Will it have TLDR?" me: "*This* is TLDR."
So... :) I discussed this on IRC with Martyn and then there was a wider discussion on #aeolus. I'll attempt to sum up the result. Anyone who disagrees with it please provide your input soon so that it can get discussed before the state transitions API implementation starts (most probably as soon as next sprint, because Winged Monkey needs it for using Conductor as a backend). There were various options discussed, from providing one global state machine for all instances, to having provider-specific state machines, to not having state machines at all and querying possible state transitions per-instance each time they are needed. On one end of the spectrum there's the one global state machine. It means a comfortable client workflow, always knowing upfront what state transitions are (and will be) available. On the other hand it could cause problems if some backend providers had weird workflows that would not map to our state machine well. Then attempts to use the state transitions listed in our state machine could end up in an error. On the other end of the spectrum there is per-instance on-demand querying to DC (this is what we do now btw). This way we would always give out information that is correct (listing only those transitions that can really be performed). On the other hand, there's no unified workflow and clients would always have to query for possible transitions on per-instance basis, right before performing a transition. It has been pointed out that for Aeolus, the abstraction of workflow is necessary and it is one of our main goals. E.g. we can have a Pool backed by multiple different cloud providers and we have to treat deployments/instances in that pool the same way. Also, to be able to represent deployment state changes consistently, we should have consistently represented instance state changes. So in the end the discussion went in favor of having a global state machine. There will be one state machine for Deployments and probably one for Instances. (There's also possibility of having two instance state machines - one for stateful and one for stateless instances. This hasn't been discussed into great depth yet, as main point of this discussion was to get Deployments/Instances API moving.) The API representation of the state machines should be like Martyn suggested [1] with one change - the <state> link embedded into <instance> [2] will be expanded to its full resource representation, to allow for reading the state value without querying the state resource separately. Please feel free to correct me if I misinterpreted anything. Take care, J. [1] https://gist.github.com/4257951 [2] https://gist.github.com/4257951#file-gistfile1-xml-L32
