[saga-rg] job states...

[Andre Merzky]

Hi Gregor, 

for most discussions in SAGA, tasks have been considered as
equivalent to threads (so exist purely for the sake of async
operations).  As such, we did not see the need for finer
control (e.g. suspend or signaling).

However, you are right, that might be too simplistic in the
long run.  

Having suspend for tasks like file transfer, and also a
resume, begs for the question of state of tasks.  Also, as
you mention, it requires support in the backend, and hence
introspection.

The use cases we have for asynchroneous operations right now
are, AFAIK, 

  - async RPC calls (not in the API right now)
  - async file and stream read/writes

The use cases for both ops are not intended to run on a
backend that supports suspend/resume.

Although the saga task model now provides async. for almost
_all_ operations, its not immediately clear to me what a
suspend state would imply in terms of semantics to these
calls.

I think that the large file transfer example you cite is the
most common use case with support for susp/resume (RFT).  We
do not have it explicitely in our use cases right now.

The only obvious case in saga are jobs, where we have the
separate suspend/resume methods.  So, you are right, if we
think of conversion between jobs and tasks, we should also
consider suspends.

It might be best to shelve that point and come back to it in
the next API version.  Well, that is a perfect task for the
upcoming RG! :-P


Well, having said that, I think its still useful to have the
task API for jobs (not vice versa).  As the task states and
methods are a real subset of the job states and methods,
that should be trivial (kind of) :-)

Cheers, Andre.



Quoting [Gregor von Laszewski] (Feb 05 2006):
> 
> I had not had the time to review all of this, but I like to suggest that 
> a "task" has also the option to be suspended or resumed.
> you also need an introspector to actually find out if for example a 
> particular feature has been implemented or not. You ma be in the need to 
> define
> NonSuspendableTasks in which you for example do not have resume or 
> suspend options. This has actually implications on how we intend to use 
> this as part of future portal developments. Hers the "tasks" could 
> encapsulate a lotincluding file transfers and job submissions ... As a 
> file transfer as wll as a job could be suspended its important that both 
> have at least the ability to be supported in that way.
> 
> Gregor
> 
> Andre Merzky wrote:
> >Nice, thanks!
> >
> >To save everybody from the need to search GrodForge, here is
> >the table from the document:
> >
> >  bes::job          saga::task   saga::job
> >
> >  New               Pending      Queued
> >  Pending           Running      Queued
> >  StagingIn         Running      PreExecution
> >  ExecutionPending  Running      PreExecution
> >  Running           Running      Running
> >  ExecutionComplete Running      PostExecution
> >  StagingOut        Running      PostExecution
> >  CleaningUp        Running      PostExecution
> >  ShuttingDown      Running      PostExecution
> >  Suspended         Running      Suspend
> >  Suspended         Running      SuspendUser
> >  Suspended         Running      SuspendSystem
> >  NotKnown          Unknown      Unknown
> >  Other             Unknown      Unknown
> >  Done              Done         DoneOK
> >  Terminated        Failed       DoneFail
> >  Exception         Failed       DoneFail
> >                                 HoldSystem
> >                                 HoldUser
> >                                 Hold
> >
> >
> >In repspect to the original topic (task/job), these map
> >fairly well to the task and job states we have, but are more
> >detailed.  I could not find an equivalent for Hold.
> >
> >Are there other models defined in GGF, or is that _THE_
> >model?
> >
> >Cheers, Andre.
> >
> >
> >
> >Quoting [Steven Newhouse] (Feb 05 2006):
> >  
> >>Date: Sun, 05 Feb 2006 07:04:28 +0000
> >>From: Steven Newhouse <s.newhouse at omii.ac.uk>
> >>To: Andre Merzky <andre at merzky.net>
> >>CC: Simple API for Grid Applications WG <saga-rg at ggf.org>
> >>Subject: Re: [saga-rg] job states...
> >>
> >>Hi Andre,
> >>
> >>The Basic Execution Service WG has done some work on defining an 
> >>activity state. You may want to have a look at that - there should be a 
> >>copy on gridforge - somewhere!
> >>
> >>Steven
> >>    



-- 
"So much time, so little to do..."  -- Garfield