airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Restricting editing and launching FAILED experiments
Date Thu, 28 Aug 2014 15:35:17 GMT
On Wed, Aug 27, 2014 at 4:05 PM, Suresh Marru <smarru@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 <marpierc@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
> >>>
> >
>
>

Mime
View raw message