On 01/02/2013 03:27 PM, Tzu-Mainn Chen wrote:
----- Original Message -----
From: "Jan Provaznik" <[email protected]> To:
[email protected] Sent: Wednesday, January 2,
2013 4:48:31 AM Subject: Re: State Transitions in ReST API
Hi, my late $0.2: Conductor abstracts (should abstract) from any
provider specific state transition differences, the state machine
should be same in all cases. I think that just documenting state
transitions in API doc would be sufficient solution.
With current Conductor capabilities, I can't think of any
reasonable use case where a developer would choose processing state
machine API. As I understood this API is required by Winged Monkey
folks - could you guys please confirm that you want/need this API?
Not sure if it's a blocker for you but implementing this feature
(state machine + API) will take at least 2 sprints (optimistic
estimation).
Jan
From the Winged Monkey perspective, we can work with either solution,
so I think we'd prefer the one that gets it out the door the fastest
:)
Mainn
Great, so in first iteration of instance/deployment API we could use
simplified format which can be finished this sprint:
https://gist.github.com/4442224#file-gistfile1-txt-L1
So Winged Moneky folks will not be blocked by waiting on state machine
implementation.
Then once we implement state machines in Conductor and it turns out that
it makes sense to expose them through API, we can extend to the
format agreed by Jirka and Martyn without breaking API compatibility:
https://gist.github.com/4442224#file-gistfile1-txt-L11
Jan
