I think experiments should be immutable irrespective of the outcomes (success/failed). Once experiment are launched I think only operations allowed on them should be cancel/pause/resume (more applicable for workflow's than single applications).
I am also + 1 for keeping any clone requests clean and facilitating further retries as a new experiment. The user can choose to clone and modify inputs/configurations and run or clone and run it again on different resources or just re-run on same resources after a time elapse (hardware changes, compiler upgrades, application version changes). But it will be nice to preserve the cloned relationship so users can analyze or virtually group them into a investigation (a virtual project). Suresh On Aug 27, 2014, at 3:47 PM, Marlon Pierce <[email protected]> wrote: > While it doesn't seem to be a problem relaunching a failed experiment, I like > the idea of just cloning and creating a new one. This eliminates some places > where things can go wrong and may make it less confusing to track things > through logs and the registry. > > Marlon > > On 8/27/14, 3:41 PM, Saminda Wijeratne wrote: >> Speaking from the experience of using CIPRES science gateway, they have >> simplified user options for a task (aka an experiment) that has being >> launched/completed/failed in to just 2 choices. >> 1. Delete Task (Cancel first if its still running) >> 2. Clone Task >> IMO from a gateway users POV this simplification is acceptable since to me >> it seems users are happy with it. However we have to understand that it's >> due to design decision made by the gateway portal designers/developers. >> i.e. If the developer thinks the community would benefit from it they would >> incorporate much broader range of choices for a task. >> eg: >> Pause >> Resume (resume paused or failed task) >> Edit >> Retry (start from the beginning) >> etc. >> Either the developer will have to implement this additional server side >> features or rely on a middleware service (aka Airavata) to do it for them. >> In either case I agree with Eroma that users should be able to see a record >> of actions performed on the task (such as when it was >> started/paused/retried, corresponding execution data etc.) >> >> >> On Mon, Aug 25, 2014 at 3:58 PM, Eroma Abeysinghe < >> [email protected]> wrote: >> >>> Hi Devs, >>> >>> Please share your views on below. In Airavata currently we can edit and >>> launch FAILED experiments; option is there through PHP gateway. >>> >>> Editing and launching FAILED experiments through PHP reference gateway >>> Currently we can edit and launch experiments with FAILED state. This can >>> create complications which can be eliminated by blocking editing and >>> launching FAILED experiments. >>> >>> If we allow editing and launch for FAILED; then we need to have a way of >>> displaying results of every attempt made on the experiment, store the >>> partial outputs, error messages and job info on each try. etc.... >>> >>> User can easily clone a failed experiment and create a new experiment. >>> So WDYT? shall we restrict Edit and launch for FAILED experiments? >>> >>> >>> -- >>> Thank You, >>> Best Regards, >>> Eroma >>> >
