These are two of the original solution suggestions for the Temporary deployment scenarios.
These have been superseded.
2) Another option would be to add an additional state.
This state could either be:
- For the “ready”/”deployed” state, i.e. the “deployed and not torn down” state (so “completed” means “torn down”), or
- For the “torn down” state (so “completed” means “ready/deployed and not torn down”)
The client would then set the desiredState property to whatever the final state was (“completed” for the first option, or “torn down” for the second option) when it has finished with the deployed resource.
Pros for the new ready/deployed state would be that “completed” is still the final state.
Pros for the new “torn down” state would be that where v2 clients use “completed” as the trigger for the next automation execution (e.g. executing tests on the deployed resource) the behaviour remains the same.
Pros for using an additional state over a separate plan: it better models the state of the deployed resource - its state is available from a single autoResult, not two separate ones.
3) An extension of option (2) would be to provide more means for providers to define the semantics of their custom states.
e.g:
- A way to flag which states are “final” (which would be used in place of checking for completed/cancelled)
- A way to indicate which states can be set as the “desiredState” (based on what the current state is)
- Some way to indicate to orchestrators which states mean that control is passed back to them (i.e. all “final” states, plus the “ready/deployed” state)
- Perhaps also some way to indicate to workers the relationship between states and their control.
Pros of this custom state semantics approach:
Cons:
- Drastically increases complexity (so clients & providers are less likely to implement it, which reduces its usefulness as a standard)
- Might end up being too specific, making some desired implementations unachievable
- May be prone to differing interpretations, which significantly impairs interoperability