#97 Reset component button
The reset component button probably should delete the contents of the output directory of the component. Currently, the old output from the run is left from before the reset (if any) which may cause a rerun to produce duplicate output files in later components.
Also, any iterator directories in the workflow/runtime component directory should also be deleted (or at least moved) so Ergatis will not display the old information when the component is rerun. Currently, if you reset a component, the component.xml is moved (to component.xml.old) and the pipeline.xml is marked as incomplete (among other changes.) This displays the component as incomplete, until the pipeline is rerun. At which point, ergatis will start to parse the i1 files and display the old information (often showing up as a bunch of failed jobs.) If we removed the i1 directory (or moved it to i1.old, for example) this would prevent old information from being displayed.
Discussion
Would also be useful is this functionality was disabled when the pipeline is stil running.
The reset button can no longer be clicked on when the pipeline is in a 'running' state.
I am looking into the oddities encountered when reset failing.
I should clarify, fixes are in place on my checkout of Ergatis and should be committed shortly.
I was unable to reproduce some of the situations Kevin described but we discussed different methods to approach a situation where reset + rerun combination and lag may spurn a user to try to rerun again and create some tricky situation where two workflow processes are running at the same time.
For the time being I've wrapped all the move and delete system commands in the reset_component.cgi script in eval's to attempt to catch when an error may occur and halt the reset process.
In the future this may be a moot point when we are submitting pipelines as SGE jobs.
I've also just encountered an issue when there were duplicate names resulting in a pre-existing $;TMP_DIR$;. We could probably remove the temporary directory as well when resetting a component.
Cesar brought up a good point though. We basically take the configured output_directory or tmp_dir and move it to .old. What if the user configured some generic place for output? For example, if they configured the output_directory to be a project repository or the temporary directory to be /tmp. Permissions might be an issue in some cases, but I'm not sure how to solve it globally.
I figured out what was causing some of the resetting issues. When a user clicks reset on a component, the output and tmp directories are moved to the same name with a .old on the end. This command is actually run as the ergatis user, no attempt is made to sudo as the currently logged in user. If the output_repository or tmp directory is not writeable by ergatis, the mv operation will fail. I believe this was what happend in the cases I saw.
With the changes Cesar implemented, the operation will fail with a permissions denied error to the user. Previously, this error was going unnoticed.
Kevin, thanks for taking the time to figure this out. I should be able to fix this as soon as I get a couple other things out of the way.
I've committed a fix for this issue as well as added confirmation for a reset considering it is a fairly destructive operation.
It has also been observed that if a user is not logged in (if authentication is enabled) and they attempt to reset a component in a pipeline it will more than likely fail in a very ugly fashion.
Ideally we'd like to avoid producing an ugly error and make use of the ergatis error page + notify the user that they are about to reset a component not logged in.