Re: [Pgi-wg] PGI State Model for discussions (ppt)
On Friday 22 May 2009 12:49, Morris Riedel wrote:
Hi PGI team,
as we discussed in going forward by discussing the state model I tried to sketch a first version inside the powerpoint file I put on GridForge:
http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc man.root.input_documents.execution_service.state_model/doc15637
Feel free to use it and make your changes that make it easier to discuss it in the next telcons / per mailing lists.
I have tried to draw a diagram similar to one we are having in ARC but extended a bit with possible use-cases I could think about. I think it makes superset of your diagram. A.K.
I also put related work about other state models inside it (HPC-FSP & BES).
Note that I created a sub-folder called state-model inside the Execution Service folder for it.
Finally, there are certainly some transitions/states that have to be discussed (i.e. sub-states hierarchy), but this version might be a good start.
Let's start with the discussion then, Morris
------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel
"We work to better ourselves, and the rest of humanity"
Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
Morris, Aleksandr and All, Concerning the OGF PGI State Model : Many thanks to Morris and Aleksandr for your proposals. We NOW have a sound technical basis permitting relevant discussion permitting to achieve agreement. Visibly, PGI requirements are much more complicated than anything reasonably achievable with the State Models presented inside BES (GFD.108) and HPC File Staging Profile (GFD.135), even with substates. Personally, even if that would break the current BES recommendation, I would prefer that all states (including D and H) are full states, in order that all transitions have precise names. Using the State Model of Aleksandr (which I like very much), we should be able to describe that 'Automatic Staging' and 'Manual Staging' can occur simultaneously. Example for simultaneous Stage-in : - As soon as the 'Execution Service' knows the Stage-in location (when the job is 'Pending' or 'Pre-Processing'), the 'Execution Service' sends the URL of the Stage-in location to the job submitter. - Automatic and Manual Stage-in can occur simultaneously inside 'Pre-processing'. - If Automatic finishes first, the job goes to 'Pre-processing:D:H', and when Manual finishes, the job can go to 'Delegated', - If Manual finishes first, the job stays inside 'Pre-processing', and when Automatic finishes, the job can go to 'Delegated'. So, I confirm that the State Model of Morris is a subset of the State Model of Aleksandr, with following tentative correspondence : Morris Aleksandr ------ --------- Created:Submitted Pending Created:Restarted Pending Pending Pending:D Running:Auto-Stage-in Pre-processing Created:Hold (Manual Stage-in) Pre-processing and Pre-processing:D:H Running:Executing Delegated Running:Hold Delegated:H Running:Auto-Stage-out Post-processing Finished:Manual-Stage-out Post-processing and Post-processing:H Finished Success Canceled (Terminated) Canceled Failed Failed-Recoverable and Failed I hope that everyone will make his/her own mind, ask questions, proposes clarifications, and helps the PGI State Model to become an stable agreed specification, leading to an OGF recommendation. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Fri, 22 May 2009, Aleksandr Konstantinov wrote:
On Friday 22 May 2009 12:49, Morris Riedel wrote:
Hi PGI team,
as we discussed in going forward by discussing the state model I tried to sketch a first version inside the powerpoint file I put on GridForge:
http://forge.gridforum.org/sf/go/doc15637?nav=1
Feel free to use it and make your changes that make it easier to discuss it in the next telcons / per mailing lists.
I have tried to draw a diagram similar to one we are having in ARC but extended a bit with possible use-cases I could think about. I think it makes superset of your diagram.
A.K.
I also put related work about other state models inside it (HPC-FSP & BES).
Note that I created a sub-folder called state-model inside the Execution Service folder for it.
Finally, there are certainly some transitions/states that have to be discussed (i.e. sub-states hierarchy), but this version might be a good start.
Let's start with the discussion then, Morris
------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel
Hi, I agree with Etienne's judgement; I also have a comment on the Pre-processing (and possibly Post-processing) state: like Aleksandr wrote in his comments to the graph, these may be complex states themselves, indeed. Just few days go an ARC developer came with an idea to create a new (sub)state for stage-in re-tries, but we so far resisted and convinced him to "hide" re-tries in the same state. It may well turn out that it still will be useful to have a distinct state for this use case. And I wouldn't deem it implementation-specific, as it is very feasible to assume that every implementation will have 0..n retries. Cheers, Oxana 22.05.2009 19:36, Etienne URBAH пишет:
Morris, Aleksandr and All,
Concerning the OGF PGI State Model :
Many thanks to Morris and Aleksandr for your proposals.
We NOW have a sound technical basis permitting relevant discussion permitting to achieve agreement.
Visibly, PGI requirements are much more complicated than anything reasonably achievable with the State Models presented inside BES (GFD.108) and HPC File Staging Profile (GFD.135), even with substates.
Personally, even if that would break the current BES recommendation, I would prefer that all states (including D and H) are full states, in order that all transitions have precise names.
Using the State Model of Aleksandr (which I like very much), we should be able to describe that 'Automatic Staging' and 'Manual Staging' can occur simultaneously.
Example for simultaneous Stage-in :
- As soon as the 'Execution Service' knows the Stage-in location (when the job is 'Pending' or 'Pre-Processing'), the 'Execution Service' sends the URL of the Stage-in location to the job submitter.
- Automatic and Manual Stage-in can occur simultaneously inside 'Pre-processing'.
- If Automatic finishes first, the job goes to 'Pre-processing:D:H', and when Manual finishes, the job can go to 'Delegated',
- If Manual finishes first, the job stays inside 'Pre-processing', and when Automatic finishes, the job can go to 'Delegated'.
So, I confirm that the State Model of Morris is a subset of the State Model of Aleksandr, with following tentative correspondence :
Morris Aleksandr ------ --------- Created:Submitted Pending Created:Restarted Pending Pending Pending:D Running:Auto-Stage-in Pre-processing Created:Hold (Manual Stage-in) Pre-processing and Pre-processing:D:H Running:Executing Delegated Running:Hold Delegated:H Running:Auto-Stage-out Post-processing Finished:Manual-Stage-out Post-processing and Post-processing:H Finished Success Canceled (Terminated) Canceled Failed Failed-Recoverable and Failed
I hope that everyone will make his/her own mind, ask questions, proposes clarifications, and helps the PGI State Model to become an stable agreed specification, leading to an OGF recommendation.
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
On Fri, 22 May 2009, Aleksandr Konstantinov wrote:
On Friday 22 May 2009 12:49, Morris Riedel wrote:
Hi PGI team,
as we discussed in going forward by discussing the state model I tried to sketch a first version inside the powerpoint file I put on GridForge:
http://forge.gridforum.org/sf/go/doc15637?nav=1
Feel free to use it and make your changes that make it easier to discuss it in the next telcons / per mailing lists.
I have tried to draw a diagram similar to one we are having in ARC but extended a bit with possible use-cases I could think about. I think it makes superset of your diagram.
A.K.
I also put related work about other state models inside it (HPC-FSP & BES).
Note that I created a sub-folder called state-model inside the Execution Service folder for it.
Finally, there are certainly some transitions/states that have to be discussed (i.e. sub-states hierarchy), but this version might be a good start.
Let's start with the discussion then, Morris
------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel
------------------------------------------------------------------------
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
Good work - I forgot the "delegated" state, which makes sense! ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Aleksandr Konstantinov -Sent: Friday, May 22, 2009 2:28 PM -To: pgi-wg@ogf.org -Subject: Re: [Pgi-wg] PGI State Model for discussions (ppt) - -On Friday 22 May 2009 12:49, Morris Riedel wrote: -> Hi PGI team, -> -> as we discussed in going forward by discussing the state model I -> tried to sketch a first version inside the powerpoint file I put on GridForge: -> -> http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi- -> wg/doc -> man.root.input_documents.execution_service.state_model/doc15637 -> -> -> Feel free to use it and make your changes that make it easier to -> discuss it in the next telcons / per mailing lists. - - I have tried to draw a diagram similar to one we are having in ARC but extended a -bit with possible use-cases I could think about. -I think it makes superset of your diagram. - - -A.K. - - -> -> I also put related work about other state models inside it (HPC-FSP & BES). -> -> Note that I created a sub-folder called state-model inside the -> Execution Service folder for it. -> -> Finally, there are certainly some transitions/states that have to be -> discussed (i.e. sub-states hierarchy), but this version might be a -> good start. -> -> -> Let's start with the discussion then, -> Morris -> -> ------------------------------------------------------------ -> Morris Riedel -> SW - Engineer -> Distributed Systems and Grid Computing Division Jülich Supercomputing -> Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 -> Juelich Germany -> -> Email: m.riedel@fz-juelich.de -> Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel -> Phone: +49 2461 61 - 3651 -> Fax: +49 2461 61 - 6656 -> -> Skype: MorrisRiedel -> -> "We work to better ourselves, and the rest of humanity" -> -> Sitz der Gesellschaft: Jülich -> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 -> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe -> Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft -> (stellv. Vorsitzender) -> ->
Morris, Aleksandr and All, Concerning the OGF PGI Job State Model (based on Aleksandr's) : I agree that Delegated includes Running. I suggest that : - Pending should be renamed as Submitted - Deep internal states do NOT need to be exposed, but states requiring User action do. - Cancellation by the User and Failure detected by the Execution Service lead to the same result, so the same state. Therefore, using the free ArgoUML tool, I have created my own proposal, which is available at http://forge.gridforum.org/sf/go/doc15655?nav=1 with the ZARGO, XMI and PNG formats. Please criticize and improve it ! Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Fri, 22 May 2009, Aleksandr Konstantinov wrote:
On Friday 22 May 2009 12:49, Morris Riedel wrote:
Hi PGI team,
as we discussed in going forward by discussing the state model I tried to sketch a first version inside the powerpoint file I put on GridForge:
http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc man.root.input_documents.execution_service.state_model/doc15637
Feel free to use it and make your changes that make it easier to discuss it in the next telcons / per mailing lists.
I have tried to draw a diagram similar to one we are having in ARC but extended a bit with possible use-cases I could think about. I think it makes superset of your diagram.
A.K.
I also put related work about other state models inside it (HPC-FSP & BES).
Note that I created a sub-folder called state-model inside the Execution Service folder for it.
Finally, there are certainly some transitions/states that have to be discussed (i.e. sub-states hierarchy), but this version might be a good start.
Let's start with the discussion then, Morris
------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel
On Wednesday 27 May 2009 22:04, Etienne URBAH wrote:
Morris, Aleksandr and All,
Concerning the OGF PGI Job State Model (based on Aleksandr's) :
I agree that Delegated includes Running.
I suggest that :
- Pending should be renamed as Submitted
- Deep internal states do NOT need to be exposed, but states requiring User action do.
- Cancellation by the User and Failure detected by the Execution Service lead to the same result, so the same state.
From my point of view job canceled by user is canceled for good. But one failed because of failure detected during job processing/execution may lead to restartable job if reason of failure may be eleminated by user action. A.K.
Therefore, using the free ArgoUML tool, I have created my own proposal, which is available at http://forge.gridforum.org/sf/go/doc15655?nav=1 with the ZARGO, XMI and PNG formats.
Please criticize and improve it !
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
On Fri, 22 May 2009, Aleksandr Konstantinov wrote:
On Friday 22 May 2009 12:49, Morris Riedel wrote:
Hi PGI team,
as we discussed in going forward by discussing the state model I tried to sketch a first version inside the powerpoint file I put on GridForge:
http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc man.root.input_documents.execution_service.state_model/doc15637
Feel free to use it and make your changes that make it easier to discuss it in the next telcons / per mailing lists.
I have tried to draw a diagram similar to one we are having in ARC but extended a bit with possible use-cases I could think about. I think it makes superset of your diagram.
A.K.
I also put related work about other state models inside it (HPC-FSP & BES).
Note that I created a sub-folder called state-model inside the Execution Service folder for it.
Finally, there are certainly some transitions/states that have to be discussed (i.e. sub-states hierarchy), but this version might be a good start.
Let's start with the discussion then, Morris
------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel
Aleksandr, Thank you very much for studying and criticizing my OGF PGI Job State Model (based on yours) : I agree that a job 'failed because of failure detected during job processing/execution may lead to restartable job if reason of failure may be eleminated by user action.' In that case, the job needs User action, so its state should be one of the following : - Pre-processing-Hold - Delegated-Hold - Post-processing-Hold Besides, I suggest that when a User cancels a job which is NOT Hold, the Execution Service simply handles that as a job failure. That permits to avoid 4 supplemental transitions toward Failed-Cancelled. Please continue to criticize ... Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Thu, 28 May 2009, Aleksandr Konstantinov wrote:
On Wednesday 27 May 2009 22:04, Etienne URBAH wrote:
Morris, Aleksandr and All,
Concerning the OGF PGI Job State Model (based on Aleksandr's) :
I agree that : - Pre-processing includes Automatic Stage-In.
- Delegated includes Running. - Post-processing includes Automatic Stage-Out.
I suggest that :
- Pending should be renamed as Submitted
- Deep internal states do NOT need to be exposed, but states requiring User action do.
- Pre-processing-Hold includes Failed-Recoverable and Manual Stage-In.
- Delegated-Hold includes Failed-Recoverable. - Post-processing-Hold includes Failed-Recoverable and Manual Stage-Out.
- Cancellation by the User and Failure detected by the Execution Service lead to the same result, so the same state.
From my point of view job canceled by user is canceled for good. But one failed because of failure detected during job processing/execution may lead to restartable job if reason of failure may be eliminated by user action.
A.K.
Therefore, using the free ArgoUML tool, I have created my own proposal, which is available at http://forge.gridforum.org/sf/go/doc15655?nav=1 with the ZARGO, XMI and PNG formats.
Please criticize and improve it !
The ArgoUML tool is open source and available for Windows, Mac OS X and Linux at http://argouml.tigris.org/
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
Hi,
I actually tend to agree with Etienne on the point that job interruption should be treated independently of the reason that caused it.
A user may want to kill a lower priority job in order to e.g. let other jobs to go ahead in the queue, and then re-start the killed job. Or if a user happens to know that the input file is not available yet, she may want to stop the job in order not to waste the resources on download attempts, and restart the job a bit later, when input appears. Or a user may suddenly realize that she had a too short (or too long) proxy, and would like to restart a job with a newer one, without changing anything else. In any such case a job is restartable, and even may be killed exactly with the purpose to restart later.
Technically, it's not quite correct to assume that users kill jobs because they never _want_ to restart them. They probably do.
Cheers,
Oxana
Etienne URBAH wrote:
> Aleksandr,
>
> Thank you very much for studying and criticizing my OGF PGI Job State
> Model (based on yours) :
>
> I agree that a job 'failed because of failure detected during job
> processing/execution may lead to restartable job if reason of failure
> may be eleminated by user action.'
>
> In that case, the job needs User action, so its state should be one of
> the following :
> - Pre-processing-Hold
> - Delegated-Hold
> - Post-processing-Hold
>
> Besides, I suggest that when a User cancels a job which is NOT Hold, the
> Execution Service simply handles that as a job failure. That permits to
> avoid 4 supplemental transitions toward Failed-Cancelled.
>
> Please continue to criticize ...
>
> Best regards.
>
> -----------------------------------------------------
> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
> Bat 200 91898 ORSAY France
> Tel: +33 1 64 46 84 87 Skype: etienne.urbah
> Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr
> -----------------------------------------------------
>
>
> On Thu, 28 May 2009, Aleksandr Konstantinov wrote:
>> On Wednesday 27 May 2009 22:04, Etienne URBAH wrote:
>>> Morris, Aleksandr and All,
>>>
>>> Concerning the OGF PGI Job State Model (based on Aleksandr's) :
>>>
>>> I agree that :
> - Pre-processing includes Automatic Stage-In.
>
> - Delegated includes Running.
>
> - Post-processing includes Automatic Stage-Out.
>
>>>
>>> I suggest that :
>>>
>>> - Pending should be renamed as Submitted
>>>
>>> - Deep internal states do NOT need to be exposed, but states
>>> requiring User action do.
>>>
> - Pre-processing-Hold includes Failed-Recoverable and Manual Stage-In.
>
> - Delegated-Hold includes Failed-Recoverable.
>
> - Post-processing-Hold includes Failed-Recoverable and Manual
> Stage-Out.
>
>>> - Cancellation by the User and Failure detected by the Execution
>>> Service lead to the same result, so the same state.
>>>
>>
>> From my point of view job canceled by user is canceled for good. But
>> one failed because of failure detected during job processing/execution
>> may
>> lead to restartable job if reason of failure may be eliminated by user
>> action.
>>
>>
>> A.K.
>>
>>
>>> Therefore, using the free ArgoUML tool, I have created my own
>>> proposal, which is available at
>>> http://forge.gridforum.org/sf/go/doc15655?nav=1 with the ZARGO, XMI
>>> and PNG formats.
>>>
>>> Please criticize and improve it !
>>>
> The ArgoUML tool is open source and available for Windows, Mac OS X
> and Linux at http://argouml.tigris.org/
>
>>> Best regards.
>>>
>>> -----------------------------------------------------
>>> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
>>> Bat 200 91898 ORSAY France
>>> Tel: +33 1 64 46 84 87 Skype: etienne.urbah
>>> Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr
>>> -----------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg@ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
--
______________________________________________________________________
Dr. Oxana Smirnova * http://www.hep.lu.se * oxana.smirnova@hep.lu.se
Institute of Physics, Dept. for Experimental High Energy Physics
Lund University Box 118, S-22100 Lund, SWEDEN
Tel. +46(46)222.76.99, +46(709)22.46.57 * Fax: +46(46)222.40.15
Hello, I would like to suggest to add every state a substate (or intermediate state) representing job being unable to go to next state due to exhausted internal resources or similar reason. A.K. On Thursday 28 May 2009 04:08, Etienne URBAH wrote:
Aleksandr,
Thank you very much for studying and criticizing my OGF PGI Job State Model (based on yours) :
I agree that a job 'failed because of failure detected during job processing/execution may lead to restartable job if reason of failure may be eleminated by user action.'
In that case, the job needs User action, so its state should be one of the following : - Pre-processing-Hold - Delegated-Hold - Post-processing-Hold
Besides, I suggest that when a User cancels a job which is NOT Hold, the Execution Service simply handles that as a job failure. That permits to avoid 4 supplemental transitions toward Failed-Cancelled.
Please continue to criticize ...
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
On Thu, 28 May 2009, Aleksandr Konstantinov wrote:
On Wednesday 27 May 2009 22:04, Etienne URBAH wrote:
Morris, Aleksandr and All,
Concerning the OGF PGI Job State Model (based on Aleksandr's) :
I agree that : - Pre-processing includes Automatic Stage-In.
- Delegated includes Running.
- Post-processing includes Automatic Stage-Out.
I suggest that :
- Pending should be renamed as Submitted
- Deep internal states do NOT need to be exposed, but states requiring User action do.
- Pre-processing-Hold includes Failed-Recoverable and Manual Stage-In.
- Delegated-Hold includes Failed-Recoverable.
- Post-processing-Hold includes Failed-Recoverable and Manual Stage-Out.
- Cancellation by the User and Failure detected by the Execution Service lead to the same result, so the same state.
From my point of view job canceled by user is canceled for good. But one failed because of failure detected during job processing/execution may lead to restartable job if reason of failure may be eliminated by user action.
A.K.
Therefore, using the free ArgoUML tool, I have created my own proposal, which is available at http://forge.gridforum.org/sf/go/doc15655?nav=1 with the ZARGO, XMI and PNG formats.
Please criticize and improve it !
The ArgoUML tool is open source and available for Windows, Mac OS X and Linux at http://argouml.tigris.org/
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
participants (4)
-
Aleksandr Konstantinov -
Etienne URBAH -
Morris Riedel -
Oxana Smirnova