[saga-rg] Job states proposal

[Andre Merzky]

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