On 12/17/2012 09:18 AM, Jiří Stránský wrote:
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
I'm ok with this assuming we can define state machines that works across
providers.
- Richard
