Restricting editing and launching FAILED experiments

[Eroma Abeysinghe <er...@gmail.com>]

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

Re: Restricting editing and launching FAILED experiments

[Raminder Singh <ra...@gmail.com>]

Based on CIPRES case, Is it a good idea to make the experiment status as DELETED or delete an experiment? If user want to filer out experiment which are failed and he does not care about it anymore. He may have already cloned it and fixed the problem. Now user have a FAILED experiment and successful experiment in the list.

We can provide some user tagging of experiments, it may help gateways to develop some filers.  +1 for allowing to clone the failed experiments. 

Thanks
Raminder
On Aug 28, 2014, at 11:35 AM, Saminda Wijeratne <sa...@gmail.com> wrote:

> 
> 
> 
> On Wed, Aug 27, 2014 at 4:05 PM, Suresh Marru <sm...@apache.org> 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 <ma...@iu.edu> 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 <
> >> eroma.abeysinghe@gmail.com> 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
> >>>
> >
> 
> 

Re: Restricting editing and launching FAILED experiments

[Saminda Wijeratne <sa...@gmail.com>]

On Wed, Aug 27, 2014 at 4:05 PM, Suresh Marru <sm...@apache.org> 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 <ma...@iu.edu> 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 <
> >> eroma.abeysinghe@gmail.com> 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
> >>>
> >
>
>

Re: Restricting editing and launching FAILED experiments

[Suresh Marru <sm...@apache.org>]

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 <ma...@iu.edu> 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 <
>> eroma.abeysinghe@gmail.com> 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
>>> 
> 

Re: Restricting editing and launching FAILED experiments

[Marlon Pierce <ma...@iu.edu>]

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 <
> eroma.abeysinghe@gmail.com> 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
>>

Re: Restricting editing and launching FAILED experiments

[Saminda Wijeratne <sa...@gmail.com>]

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 <
eroma.abeysinghe@gmail.com> 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
>