Torque/PBS DRMAA - drmaa_wi* POSIX equivalents II
Issue: Removing drmaa_wif* routines and introducing one-call semantics could lead to more clear, consistent and informative job life cycle graph. For example, additionally to the existing job states returned by drmaa_job_ps(), we could imagine also states such as DRMAA_JOB_PS_COREDUMPED or DRMAA_JOB_PS_SIGNALLED. --------- If the drama_w* functions are present, this is not necessary. If one day the drama_wif* routines are gone, we might need extensions mechanism (like some other groups, JSDL or SAGA?) for the job states to avoid explosions of states and implementation complexity. This is clearly future versions staff. -Hrabri
Issue:
Removing drmaa_wif* routines and introducing one-call semantics could lead to more clear, consistent and informative job life cycle graph. For example, additionally to the existing job states returned by drmaa_job_ps(), we could imagine also states such as DRMAA_JOB_PS_COREDUMPED or DRMAA_JOB_PS_SIGNALLED. ---------
If the drama_w* functions are present, this is not necessary.
If one day the drama_wif* routines are gone, we might need extensions mechanism (like some other groups, JSDL or SAGA?) for the job states to avoid explosions of states and implementation complexity. This is clearly future versions staff.
OGSA-BES had some long discussion about job states, we should look on this. JSDL is no option here, since their job is over after the job submission. I vote for an updated field study, where we compare the available job state information in the most prominent DRM systems. The key is to find the least common denominator - therefore this would be the chance to remove the different SUSPENDED states ;-) Peter.
The nice thing about the BES (and SAGA) state model is that it is rather simple, and probably represents a common denominator for many systems. At the same time, it can easily cover backend specific substates (e.g. the DRMAA distinction for two different SUSPENDED states would be modeled as substates to one SUSPENDED state). These substates are, however, (mostly) for informational purposes. Anyway, I'd like to encourage you to check the BES/SAGA state model in detail. Its probably better described in the BES doc, but possibly easier to understand in the SAGA spec ;-) It would be nice if we could agree on one common job state model at some point in the future... Cheers, Andre. Quoting [Peter Troeger] (May 04 2007):
From: Peter Troeger <peter.troeger@hpi.uni-potsdam.de> To: DRMAA Working Group <drmaa-wg@ogf.org> Subject: Re: [DRMAA-WG] Torque/PBS DRMAA - drmaa_wi* POSIX equivalents II
Issue:
Removing drmaa_wif* routines and introducing one-call semantics could lead to more clear, consistent and informative job life cycle graph. For example, additionally to the existing job states returned by drmaa_job_ps(), we could imagine also states such as DRMAA_JOB_PS_COREDUMPED or DRMAA_JOB_PS_SIGNALLED. ---------
If the drama_w* functions are present, this is not necessary.
If one day the drama_wif* routines are gone, we might need extensions mechanism (like some other groups, JSDL or SAGA?) for the job states to avoid explosions of states and implementation complexity. This is clearly future versions staff.
OGSA-BES had some long discussion about job states, we should look on this. JSDL is no option here, since their job is over after the job submission.
I vote for an updated field study, where we compare the available job state information in the most prominent DRM systems. The key is to find the least common denominator - therefore this would be the chance to remove the different SUSPENDED states ;-)
Peter. -- "XML is like violence: if it does not help, use more."
Actually the idea of having kind of a general pupose state definition framework model was discussed very, very early within DRMAA-WG. At that point in time the workgroup decided not to pursue this and I think this was good since I never heard such a request from the DRMAA user community. Regards, Andreas Until now DRMAA users have not stated demand. On Sat, 5 May 2007, Andre Merzky wrote:
The nice thing about the BES (and SAGA) state model is that it is rather simple, and probably represents a common denominator for many systems.
At the same time, it can easily cover backend specific substates (e.g. the DRMAA distinction for two different SUSPENDED states would be modeled as substates to one SUSPENDED state). These substates are, however, (mostly) for informational purposes.
Anyway, I'd like to encourage you to check the BES/SAGA state model in detail. Its probably better described in the BES doc, but possibly easier to understand in the SAGA spec ;-)
It would be nice if we could agree on one common job state model at some point in the future...
Cheers, Andre.
Quoting [Peter Troeger] (May 04 2007):
From: Peter Troeger <peter.troeger@hpi.uni-potsdam.de> To: DRMAA Working Group <drmaa-wg@ogf.org> Subject: Re: [DRMAA-WG] Torque/PBS DRMAA - drmaa_wi* POSIX equivalents II
Issue:
Removing drmaa_wif* routines and introducing one-call semantics could lead to more clear, consistent and informative job life cycle graph. For example, additionally to the existing job states returned by drmaa_job_ps(), we could imagine also states such as DRMAA_JOB_PS_COREDUMPED or DRMAA_JOB_PS_SIGNALLED. ---------
If the drama_w* functions are present, this is not necessary.
If one day the drama_wif* routines are gone, we might need extensions mechanism (like some other groups, JSDL or SAGA?) for the job states to avoid explosions of states and implementation complexity. This is clearly future versions staff.
OGSA-BES had some long discussion about job states, we should look on this. JSDL is no option here, since their job is over after the job submission.
I vote for an updated field study, where we compare the available job state information in the most prominent DRM systems. The key is to find the least common denominator - therefore this would be the chance to remove the different SUSPENDED states ;-)
Peter. -- "XML is like violence: if it does not help, use more."
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
http://gridengine.info/ Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
Hi Andreas, Quoting [Andreas.Haas@Sun.COM] (May 08 2007):
Actually the idea of having kind of a general pupose state definition framework model was discussed very, very early within DRMAA-WG. At that point in time the workgroup decided not to pursue this and I think this was good since I never heard such a request from the DRMAA user community.
Well, DRMAA was around much earlier than BES or SAGA or many other groups - so I'm certainly not saying you should have used this model :-) Also, you are right: don't fix it if it ain't broken... If users are happy, than thats a good measurement for success... Cheers, Andre.
Regards, Andreas
Until now DRMAA users have not stated demand.
On Sat, 5 May 2007, Andre Merzky wrote:
The nice thing about the BES (and SAGA) state model is that it is rather simple, and probably represents a common denominator for many systems.
At the same time, it can easily cover backend specific substates (e.g. the DRMAA distinction for two different SUSPENDED states would be modeled as substates to one SUSPENDED state). These substates are, however, (mostly) for informational purposes.
Anyway, I'd like to encourage you to check the BES/SAGA state model in detail. Its probably better described in the BES doc, but possibly easier to understand in the SAGA spec ;-)
It would be nice if we could agree on one common job state model at some point in the future...
Cheers, Andre.
Quoting [Peter Troeger] (May 04 2007):
From: Peter Troeger <peter.troeger@hpi.uni-potsdam.de> To: DRMAA Working Group <drmaa-wg@ogf.org> Subject: Re: [DRMAA-WG] Torque/PBS DRMAA - drmaa_wi* POSIX equivalents II
Issue:
Removing drmaa_wif* routines and introducing one-call semantics could lead to more clear, consistent and informative job life cycle graph. For example, additionally to the existing job states returned by drmaa_job_ps(), we could imagine also states such as DRMAA_JOB_PS_COREDUMPED or DRMAA_JOB_PS_SIGNALLED. ---------
If the drama_w* functions are present, this is not necessary.
If one day the drama_wif* routines are gone, we might need extensions mechanism (like some other groups, JSDL or SAGA?) for the job states to avoid explosions of states and implementation complexity. This is clearly future versions staff.
OGSA-BES had some long discussion about job states, we should look on this. JSDL is no option here, since their job is over after the job submission.
I vote for an updated field study, where we compare the available job state information in the most prominent DRM systems. The key is to find the least common denominator - therefore this would be the chance to remove the different SUSPENDED states ;-)
Peter. -- "XML is like violence: if it does not help, use more."
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
-- "XML is like violence: if it does not help, use more."
Hi Andre, All, Andre Merzky pisze:
Hi Andreas,
Quoting [Andreas.Haas@Sun.COM] (May 08 2007):
Actually the idea of having kind of a general pupose state definition framework model was discussed very, very early within DRMAA-WG. At that point in time the workgroup decided not to pursue this and I think this was good since I never heard such a request from the DRMAA user community.
Well, DRMAA was around much earlier than BES or SAGA or many other groups - so I'm certainly not saying you should have used this model :-)
Also, you are right: don't fix it if it ain't broken... If users are happy, than thats a good measurement for success...
Cheers, Andre.
I do support Andre's comments... I think a state definition model in next DRMAA specs should be improved or at least discussed again to reflect some new requirements and also best practices and ideas taken from SAGA and BES. I'd like to encourage you to check out the section 3.1.2. Job States we proposed in Open DRMAA Service Provider (OpenDSP) v1.0 http://downloads.sourceforge.net/opendsp/dsp-manual-1.0.tar.gz?modtime=1162140031&big_mirror=0 Actually, when we have been discussing next OpenDSP releases a new question appeared: how/when can we support BES 1.0? Hence, we are interested in the convergence among DRMAA, SAGA and BES discussions around state model as well as new routines for job status change monitoring such as transition into the PENDING and RUNNING states. Thanks, Chris
Regards, Andreas
Until now DRMAA users have not stated demand.
On Sat, 5 May 2007, Andre Merzky wrote:
The nice thing about the BES (and SAGA) state model is that it is rather simple, and probably represents a common denominator for many systems.
At the same time, it can easily cover backend specific substates (e.g. the DRMAA distinction for two different SUSPENDED states would be modeled as substates to one SUSPENDED state). These substates are, however, (mostly) for informational purposes.
Anyway, I'd like to encourage you to check the BES/SAGA state model in detail. Its probably better described in the BES doc, but possibly easier to understand in the SAGA spec ;-)
It would be nice if we could agree on one common job state model at some point in the future...
Cheers, Andre.
Quoting [Peter Troeger] (May 04 2007):
From: Peter Troeger <peter.troeger@hpi.uni-potsdam.de> To: DRMAA Working Group <drmaa-wg@ogf.org> Subject: Re: [DRMAA-WG] Torque/PBS DRMAA - drmaa_wi* POSIX equivalents II
Issue:
Removing drmaa_wif* routines and introducing one-call semantics could lead to more clear, consistent and informative job life cycle graph. For example, additionally to the existing job states returned by drmaa_job_ps(), we could imagine also states such as DRMAA_JOB_PS_COREDUMPED or DRMAA_JOB_PS_SIGNALLED. ---------
If the drama_w* functions are present, this is not necessary.
If one day the drama_wif* routines are gone, we might need extensions mechanism (like some other groups, JSDL or SAGA?) for the job states to avoid explosions of states and implementation complexity. This is clearly future versions staff.
OGSA-BES had some long discussion about job states, we should look on this. JSDL is no option here, since their job is over after the job submission.
I vote for an updated field study, where we compare the available job state information in the most prominent DRM systems. The key is to find the least common denominator - therefore this would be the chance to remove the different SUSPENDED states ;-)
Peter.
-- "XML is like violence: if it does not help, use more."
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
participants (5)
-
Andre Merzky -
Andreas.Haas＠Sun.COM -
Krzysztof Kurowski -
Peter Troeger -
Rajic, Hrabri