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