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@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@xxxxxxx> Subject: [saga-rg] Job states proposal From: Christopher Smith <csmith@xxxxxxxxxxxx> Date: Thu, 16 Feb 2006 05:05:15 -0800 Delivered-to: grdfm-saga-rg-outgoing@mailbouncer.mcs.anl.gov Delivered-to: grdfm-saga-rg@mailbouncer.mcs.anl.gov Sender: owner-saga-rg@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