Morris and All, Concerning the PGI Job State Model : - Thank you very much for having taken the time to analyze my proposal. - Your remarks are relevant : Although my UML model already contained the desired internal states, the rendering diagram which I had created was too small to display the internal states. To address your remarks : - I enlarged the rendering diagram in order to clearly display the internal states (like inside the 'CREAM job state diagram'), in particular Data-Staging (1) and Failed-Recoverable (2), - I renamed the internal states in order to clearly show the hierarchy, in particular Delegated:Running (3). Inside http://forge.gridforum.org/sf/go/doc15655?nav=1 : I saved the improved model on Thursday 11 June 2009 under 3 formats : - ZARGO file created by ArgoUML - XMI file readable by any UML tool - PNG drawing I hope that the model is clearer now, and I am ready for further improvements. I am sorry not being able to attend the PGI telephone conferences this week : - On Wednesday 10 June, I was involved in an EDGeS face to face meeting. - On Friday 12 June 2009, I will NOT be able to attend either. 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 Wed, 10 Jun 2009, m.riedel@fz-juelich.de wrote:
Hi all,
I try to summarize the analysis of the state model, which we took as a basis on the telcon:
http://forge.ogf.org/sf/docman/do/downloadDocument/projects.pgi-wg/docman.ro... (doc15655: PGI Job State Model (available as ZARGO, XMI and PNG) )
This state model is a good starting point for discussion, however an analysis reveal still a few uncertain points:
(1) Data-staging is not indicated although required - in that context we might even distinguish between manual/auto data-staging states
(2) A restart state/possibility/transition is required at least for failed jobs - in that context it might even worth to consider restarts of successful jobs that might only operated on 'wrong data' manually provided by the end-user during stagings - benefit: keep descriptions of jobs
(3) reflection of hierarchy: Initially in Geneva we agreed to have kind of an approach to get a hierarchical process update. In other words, once a job is delegated, we also want to know whether the job is in delegated:Running or delegated:Pending and such like. Hence, we need an approach of describing hierarchies in the state model missing in the current version.
We have an agreement between gLite, ARC, & UNICORE once these points are part of the state model.
Did I forgot something? Please add your comments.
Take care, Morris
-------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel
Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel