If a task fails, we can either:
* allow other task ops to be called - we cannot do this because the ops are fine-grained. for example,
a restore failure removes many things and calling set-memory or set-location in that state won't
make sense.
* provide a generic repair route - this allows one to override args and call the failed task
again. this is what we have now but has the issue that this repair function has to know about all
the other op functions. for example, for argument validation. we can do some complicated refactoring
to make it work if we want.
* just a generic total re-configure - this does not work because clone/restore/backup/datadir/uninstall/update
failure leaves the app in a state which re-configure cannot do anything about.
* allow the failed op to be called again - this seems the easiest. we just allow the route to be called again
in the error state.
* if we hit a state where even providing extra args, cannot get you out of this "error" state, we have to provide
some repair route. for example, maybe the container disappeared by some docke error. user clicks 'repair' to
recreate the container. this route does not have to take any args.
The final solution is:
* a failed task can be called again via the route. so we can resubmit any args and we get validation
* repair route just re-configures and can be called in any state to just rebuild container. re-configure is also
doing only local changes (docker, nginx)
* install/clone failures are fixed using repair route. updated manifest can be passed in.
* UI shows backup selector for restore failures
* UI shows domain selector for change location failulre
Johannes Zellner