airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: Delete methods in the API
Date Fri, 23 May 2014 14:08:45 GMT
The API could allow explicit archiving in addition to the system policy conditions like you
list below.

Either way, we need to add the field archive and have it false by default and make it true
on API call or system decisions. We then need to augment the get operations to honor the archive
flag and have a new method to retrieve archived experiments. 


On May 23, 2014, at 9:43 AM, Saminda Wijeratne <> wrote:

> IMO archive experiment for a gateway could happen based on a criteria. EG: archive all
experiments performed before (or between) <some_date(s)>, archive <user> experiments.
archive <project> experiment done before <some_date> which has status <some_status>,
archive <expId1>,<expId2>.... etc. 
> How this is translated in to Airavata API however will need some thinking.
> On Fri, May 23, 2014 at 5:50 AM, Marlon Pierce <> wrote:
> I think we can live without "deleteProject" since they are just
> containers of experiments.
> How about archiveExperiment(expId) instead of deleteExperiment(expId)?
> This could be implemented in few different ways, but it would not
> involve the complications of deleting the experiment.
> Marlon
> On 5/23/14 8:37 AM, Suresh Marru wrote:
> > On May 19, 2014, at 5:39 PM, Marlon Pierce <> wrote:
> >
> >> We need to be able to delete projects and experiments, but there are no
> >> API methods for this.  I realize this is raises some problems for
> >> experiments that have been launched (I put this in the API summary [1],
> >> but I suggest the following intermediate steps:
> > For the reasons stated in the doc, delete is complex. How about the following to
start with:
> >
> >> * Have a method to delete Experiments that have not been launched yet.
> > How about  deleteExperiment($experimentID) - currently only support delete unlaunched.
In the future we may want to mark a flag “active” to true or false base on if anything
is going on with this experiment. I feel this is more authoritative then statuses. For instance,
there can be race conditions on states changes and delete actions. Instead, we can make this
simple by having a semaphore on an active flag.
> >
> >> * Have a method to delete Projects that only consist of unlaunched
> >> Experiments.
> > I think cascade deletion of projects and experiments within it (even conditional
delete) will need to thought out more. How about we only deletion of empty projects for now?
That means, the gateway is expected to delete all experiments and then the project. Not optimal
but to minimize side effects for now.
> >
> > Suresh
> >
> >> * Otherwise, throw Exceptions ("Can only remove unlaunched experiments",
> >> "Can't remove projects that contain launched experiments").
> >>
> >> Marlon
> >>
> >> [1]
> >>

View raw message