I saw that Peter created a new Idea for "Rollback a Workflow" : http://communities.netapp.com/ideas/1094
This concept has been a common discussion point with customers. Ultmately the customers have said that they wanted a 'Rollback option" for when a workflow fails they've also agreed that it is better to STOP and identify what went wrong, and to not automatically rollback. Also, some workflows will not be possible to 'rollback'. Think decommissioning in this instance. if some volumes are offlined and destroyed as part of a 'Decommissioning' workflow... then it will not be possible to "rollback" those actions. Once the volumes are gone... then they're gone. Another workflow would have to be run to recreate them.
The current method for "Rollback" is to have a specific "Decommission" or "DeProvisioning" workflow that can remove the objects that are created as part of a workflow. The "Decommissioning" workflow would look to see if the volume, qtree, vFiler, aggregate... whatever exists in the environment and would offline/destroy, remove that object if it exists... or skip it if it doesn't exist (workflow doesn't "find" it). Yes, this would require another workflow to be created, but it would put control into the customer's hands for if it would be necessary to remove compnents created by a particular workflow.
Conversly, there have also been discussions for having a "Restart Workflow". This is where a workflow could be restarted where it failed, if necessary. Think of a workflow failing for an out of space condition or a possible socket error where some options on the storage controller weren't configured properly. Once the issues were corrected, then the wokflow could be restarted where it failed. A "Restart Workflow" feature is being planned for a future WFA release.
If everyone viewing this discussion can go and vote either for or against the idea (http://communities.netapp.com/ideas/1094) we can have a better understanding for IF this is a priority and should be focused on for one of the upcomming releases.
I don't have a problem with requiring additional workflows to make things happen: i can see where automatic rollback would be more trouble than it's worth.
I would like an opportunity to do some kind of error catching/handling during the course of a workflow's command execution.
So if you like, i'm asking for the facility to implement rollback (or other error handling), rather than having some magic auto-rollback built-in.
I voted up. I like the idea of WFA generating a workflow that contains the commands to roll-back what was done so-far - but not automatically executing it. That way, its up to the workflow administrator to determine if he/she wants to execute that "rollback" wokflow. If they don't, they can just ignore or delete that "rollback" workflow.
Definitely a nice-to-have feature, but I'm not sure its a must-have feature.
I also Vote for this functionality."rollback" functionality is useful in some cases.
We have standard name for the Root Volume(gotv902xxx).After renaming it,we need to changed the couple of options(like create_ucode,conver_ucode).
In my Workflow,Renaming volume completed successfully but modify volume failed.So i want to rollback the changes before troubleshoot.
The workflow scenario that you have mentioned in your example has been addressed in the upcoming WFA release as part of a new feature to handle such cases.
The workflow should now go through successfully.
NOTE: The rollback functionality is still an open topic.