State Transitions in ReST API
Richard Su
rwsu at redhat.com
Tue Dec 18 01:41:50 UTC 2012
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
More information about the aeolus-devel
mailing list