Hi. May I disagree with this SAGA states? In our use case (GRID superscalar) it is important to know when the transfering of input files end when a job has been submitted (this transfered files can be used by other jobs). I don't see how you can know that in this state diagram. Cheers. Raul. Andre Merzky wrote:

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 To: Christopher Smith Cc: Simple API for Grid Applications WG 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 To: Simple API for Grid Applications WG

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

------------------------------------------------------------------------

Andre Merzky wrote:

Quoting [Raul Sirvent] (Feb 20 2006):

...

Hi. May I disagree with this SAGA states?

Sure :-)

...

In our use case (GRID superscalar) it is important to know when the transfering of input files end when a job has been submitted (this transfered files can be used by other jobs). I don't see how you can know that in this state diagram.

You would do the following:

void print_job_state (saga::job & j) { cout << "job state: " << j.get_state () << " - " << j.get_state_detail () << endl; }

void run_job (saga::job_decription & jd) { saga::job_server js; saga::job j = js.create (jd);

print_job_state (j); // job state: "New" - "BES:New"

j.run ();

print_job_state (j); // job state: "Running" - "BES:Pending"

sleep (1); print_job_state (j); // job state: "Running" - "BES:StagingIn"

sleep (1); print_job_state (j); // job state: "Running" - "BES:Running"

sleep (1); print_job_state (j); // job state: "Running" - "BES:StagingOut"

sleep (1); print_job_state (j); // job state: "Done" - "BES:Done" }

You would be able to monitor both the simple saga job state, as the more verbose job_state_detail. For both you can add callbacks which would notify you on state changes asynchroneously.

Does that make sense to you?

The prints would be enums for state, and strings for state details. Also, the method names might be slightly different - so the code is not 100% correct - however, it should be close, and I hope its illustrative :-)

Yes, it is clear now. Many thanks Andre. Raul.

Cheers, Andre.

...

Cheers. Raul.

Andre Merzky wrote:

...

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 To: Christopher Smith Cc: Simple API for Grid Applications WG 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 To: Simple API for Grid Applications WG

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

------------------------------------------------------------------------