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