[ogsa-bes-wg] Input from SAGA to BES State Discussion

[Christopher Smith]

Let me clarify ... 

The model proposed to the SAGA group is not derived in whole from BES, but I
would encourage BES to adopt the same model. It was proposed first to the
SAGA group, because at the last GGF discussions came up around the state
model. I was going to comment on BES's model in the same way when it had
gone into public comment, since the spec is at that stage.

It's just a timing issue...

-- Chris


On 20/4/06 09:24, "Andre Merzky" <andre at merzky.net> wrote:

> Please note that SAGA tries to follow the BES model.  Chris
> Smith, the author of the cited mail, is feeding the BES
> results from time to time into the SAGA group
> 
> So, if BES starts to look on our model for input, we might
> be running in circles ;-)
> 
> Cheers, Andre.
> 
> 
> Quoting [David Snelling] (Apr 20 2006):
>> 
>> Folks,
>> 
>> This mail seem relevant to making progress on the BES state model
>> revisions:
>> 
>> http://www-unix.gridforum.org/mail_archive/saga-rg/2006/02/msg00107.html
>> 
>> For your connivence:
>> 
>>> To: Simple API for Grid Applications WG <saga-rg at xxxxxxx>
>>> Subject: [saga-rg] Job states proposal
>>> From: Christopher Smith <csmith at xxxxxxxxxxxx>
>>> Date: Thu, 16 Feb 2006 05:05:15 -0800
>>> Delivered-to: grdfm-saga-rg-outgoing at mailbouncer.mcs.anl.gov
>>> Delivered-to: grdfm-saga-rg at mailbouncer.mcs.anl.gov
>>> Sender: owner-saga-rg at xxxxxxx
>>> Thread-index: AcYy+aCk32NXk57sEdqikQAKlc1slg==
>>> Thread-topic: Job states proposal
>>> User-agent: Microsoft-Entourage/11.2.1.051004
>>> 
>>> 
>>> 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
>>> 
>>> 
>>> 
>> 
>> Take care:
>> 
>>       David Snelling David . Snelling . UK . Fujitsu . com
>>       Fujitsu Laboartories of Europe
>> 
> 
>