Quoting [Christopher Smith] (May 02 2006):
Hi all,
As Marvin mentioned in his email on extensibility and composition of protocols, I'd like to present this short document describing, in more detail, a model for extending the state model of jobs from a "base profile". The document is based on some discussions that Marvin and I have been having about scheduler interoperability, and is very close to the model that has been proposed within the SAGA working group. Please review Marvin's email about extensibility to get a feel for the "context" of the model.
It is my intention to show how the ESI and BES state models can be represented using this approach. I'll try to get that done before Tokyo, but might just need to present some slides at GGF17, assuming I'm given a few minutes to do so.
This is very much a work in progress, so I'm looking forward to feedback....
A note for the SAGA group .... I'd still like to see "pending" in the base job state diagram ... don't know why it disappeared. ;-)
Right now its absent because only those states which can be actually reached by SAGA method calls are present. Now, as you said earlier, it can be assumed a flaw that SAGA has no means to put a job into 'Pending' state. So, if there are some use cases or some agreement that the API should allow to move a job into 'Pending' state, the method/attribute will be added, and the state will be added. Similar reasoning holds for 'Suspend' - as long as we don't have suspend/resume methods, we would not like to expose a 'Suspended' state on the higher level state diagram. Well, thats my opinion at least ;-) I know that you see Pending as crucial. IIUC, that funds (partly) on the fact that most/all Queuing systems support pending. However, SAGA is right now not about submissing to queues in the first place, so I am not sure if that is relevant (right now). Could we discuss that in Tokyo? Some (real) use cases would be very convincing. Thanks, best regards, Andre.
-- Chris
-- "So much time, so little to do..." -- Garfield