The default reflex when a deployment fails is usually to look at the server logs, understand (perhaps guess) what has gone wrong, modify the deployment and re-run. If the error is obvious, then this is probably the easiest and most straightforward tactic.
However, if the logs are not clear, then it is better to debug the deployment while it is running.
First ensure that you've used the option to keep the deployment running "always" (on success and on error). This will prevent SlipStream from terminating the machines when the SlipStream processing ends.
$ source /opt/slipstream/client/slipstream.setenv
SlipStream tries hard not to disrupt the VMs it deploys, so setting up the SlipStream client environment is not done by default.
If your deployment has failed, any further calls to SlipStream commands such as ss-get and ss-set will also fail. This behavior is there to ensure that failures happen quickly, without waiting for potentially long timeouts. To reset the abort flag, issue the following command:
$ ss-abort --cancel
From this point on, you will be able to re-run the deployment execution scripts, which are available in the "/tmp/tmp*" files. You can then iterate on these scripts until you've understood and corrected any deployment problems.
Be sure to copy the corrected scripts back into the node definitions!