On Wed, Aug 27, 2014 at 4:05 PM, Suresh Marru <[email protected]> wrote:
> 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). > +1. I'd say allow putting tags to an experiment. Then the gateways can query experiments by a list of tags as the filtering criteria. It'll be the gateways responsibility to manipulate the tags to the experiment whatever the way they want. > 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 > >>> > > > >
