[saga-rg] Job states proposal

[Andre Merzky]

As addition, please see attached the updated SAGA state
diagram.  Note that the BES states are taken from the BES
doc.  The SAGA states would then apply to both jobs and
tasks, with the same semantics.  The task cancelled state
would be folded into the Failed state.  The Cancelling state
we discussed in Athens would be ShuttingDown, so a sub state
of Running.

Cheers, Andre.


Quoting [Andre Merzky] (Feb 17 2006):
> Date: Fri, 17 Feb 2006 21:26:58 +0200
> From: Andre Merzky <andre at merzky.net>
> To: Christopher Smith <csmith at platform.com>
> Cc: Simple API for Grid Applications WG <saga-rg at ggf.org>
> Subject: Re: [saga-rg] Job states proposal
> 
> Hi Chris, 
> 
> thanks for the discussions at GGF, and for this proposal!
> 
> I am supportive of the proposal.  It basically means that we
> maintain a very simple state model for SAGA, with a very
> finite number of states - but allow a more detailed state
> model to be exposed if needed.  I am all for it.
> 
> As for the suspend and hold state: I would, contrary to
> Chris, move the hold state into the details, and only expose
> the suspend state.  Reason would be that we have 
> suspend/resume methods, but no hold, and no use cases for
> hold.  
> 
> Well, Chris' argument to that was, IIRC, that we actually
> should have hold (as a flag to submit), as it is supported
> by most backends.
> 
> I guess that is a minor detail, either way will work fine at
> the end
> 
> Cheers, Andre.
> 
> 
> 
> Quoting [Christopher Smith] (Feb 16 2006):
> > Date: Thu, 16 Feb 2006 05:05:15 -0800
> > Subject: [saga-rg] Job states proposal
> > From: Christopher Smith <csmith at platform.com>
> > To: Simple API for Grid Applications WG <saga-rg at ggf.org>
> > 
> > Ok ... here's my proposal for modelling the SAGA job states.
> > 
> > There is a typical path through the states:
> > 
> > New --> Pending --> Running --> Finished
> > 
> > You could also submit with a hold, or put a Pending job on hold:
> > 
> > New --> Hold <--> Pending
> > 
> > You can suspend a job (and resume it):
> > 
> > Running <--> Suspended
> > 
> > The job can fail in execution:
> > 
> > Running --> Failed
> > 
> > And the job can be cancelled:
> > 
> > Running --> Cancelled
> > New --> Cancelled
> > Pending --> Cancelled
> > Suspended --> Cancelled
> > 
> > All states can go to "Unknown".
> > 
> > Let's not bother modelling User and System suspended and hold states,
> > pending some more experience and let's not bother with all the pre/post
> > states and file staging stuff pending experience and use cases, but see
> > below on extended states.
> > 
> > This model pretty much preserves what we had before (adding unknown, I
> > believe), and it represents the "basic" SAGA state model.
> > 
> > Now ... in order to have the ability to add states (say to support the BES
> > state model), we can define a class for JobState that contains the BaseState
> > (one of the enumerated states from above) and that has an ExtendedState
> > attribute defined as a vector of strings. The job can then represent some of
> > the extended states such as "Running PreExecution" or "Running StagingIn",
> > etc, etc. By using the attribute mechanism, coders can get started with SAGA
> > implementations now, and as we extend the state model according to
> > experience and use cases, we merely need to specify acceptable strings,
> > rather than change the underlying data structures.
> > 
> > My $0.02
> > 
> > -- Chris
-- 
"So much time, so little to do..."  -- Garfield
-------------- next part --------------
A non-text attachment was scrubbed...
Name: job_states.png
Type: image/png
Size: 45439 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/saga-rg/attachments/20060219/68e526ff/attachment-0003.png