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. Suresh On May 23, 2014, at 9:43 AM, Saminda Wijeratne <[email protected]> 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 <[email protected]> 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 <[email protected]> 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] > >> https://cwiki.apache.org/confluence/display/AIRAVATA/Airavata+API+Overview > >
