RE: [drmaa-wg] DRMAA test case for malicous job template input parameter
We are in the gray area I would say. A test code could reflect that. DRMAA state diagram has a valuator stage that could reject a job like it happened here for Condor. Sometimes these discrepancies happen due to quality of DRMAA implementation, sometimes due to DRM architecture. This is inevitable and we have agreed to have some latitude in the spec to reflect the realities in the marketplace. Regards Hrabri
-----Original Message----- From: owner-drmaa-wg@ggf.org [mailto:owner-drmaa-wg@ggf.org] On Behalf Of Andreas Haas Sent: Friday, September 30, 2005 10:48 AM To: Peter Troeger Cc: DRMAA Working Group Subject: Re: [drmaa-wg] DRMAA test case for malicous job template input parameter
Hi Peter,
On Fri, 30 Sep 2005, Peter Troeger wrote:
Hi,
the SGE DRMAA test suite has a set of three tests for checking the behavior in case of incorrect job template settings for the input, output, or error file path. The following text is the description of the test case:
/* - drmaa_init() is called - a job is submitted with input/output/error path specification that must cause the job to fail - use drmaa_synchronize() to ensure job was started - drmaa_job_ps() must return DRMAA_PS_FAILED - drmaa_wait() must report drmaa_wifaborted() -> true - then drmaa_exit() is called */
The funny thing is that the test case expects the (wrong) template to be accepted by drmaa_run_job(), and then expects that the job status changes to FAILED.
This is due to sentences such as
"If set, and the file can't be read, the job enters the state DRMAA_PS_FAILED. The attribute name is drmaa_input_path."
in DRMAA spec.
The Condor implementation rejects the job template at submission time with DRMAA_ERRNO_DENIED_BY_DRM, which is in my opinion the right approach according to the spec.
Possibly with the Condor implementation a "drmaa_transfer_files" setting "ioe" is in effect by default. This would imply these files are located at the submit machine. At least this would be an explaination how Condor can detect at submit time these pathes are invalid.
In case of Grid Engine "DRMAA_PS_FAILED" is returned as the defectiveness of these pathes at the execution machine can't be determined before the try to start the job.
Regards, Andreas
I am not sure whether or not this was clarified in today's DRMAA conference. I vote for a tracker item, since the spec should clearly formulate that both options (error during submission vs. failed state of the job) are possible for an invalid job template. Regards, Peter. Am 30.09.2005 um 18:01 schrieb Rajic, Hrabri:
We are in the gray area I would say.
A test code could reflect that.
DRMAA state diagram has a valuator stage that could reject a job like it happened here for Condor.
Sometimes these discrepancies happen due to quality of DRMAA implementation, sometimes due to DRM architecture. This is inevitable and we have agreed to have some latitude in the spec to reflect the realities in the marketplace.
Regards
Hrabri
-----Original Message----- From: owner-drmaa-wg@ggf.org [mailto:owner-drmaa-wg@ggf.org] On Behalf
Of
Andreas Haas Sent: Friday, September 30, 2005 10:48 AM To: Peter Troeger Cc: DRMAA Working Group Subject: Re: [drmaa-wg] DRMAA test case for malicous job template input parameter
Hi Peter,
On Fri, 30 Sep 2005, Peter Troeger wrote:
Hi,
the SGE DRMAA test suite has a set of three tests for checking the behavior in case of incorrect job template settings for the input, output, or error file path. The following text is the description of the test case:
/* - drmaa_init() is called - a job is submitted with input/output/error path specification that must cause the job to fail - use drmaa_synchronize() to ensure job was started - drmaa_job_ps() must return DRMAA_PS_FAILED - drmaa_wait() must report drmaa_wifaborted() -> true - then drmaa_exit() is called */
The funny thing is that the test case expects the (wrong) template to be accepted by drmaa_run_job(), and then expects that the job status changes to FAILED.
This is due to sentences such as
"If set, and the file can't be read, the job enters the state DRMAA_PS_FAILED. The attribute name is drmaa_input_path."
in DRMAA spec.
The Condor implementation rejects the job template at submission time with DRMAA_ERRNO_DENIED_BY_DRM, which is in my opinion the right approach according to the spec.
Possibly with the Condor implementation a "drmaa_transfer_files"
setting
"ioe" is in effect by default. This would imply these files are located at the submit machine. At least this would be an explaination how
Condor
can detect at submit time these pathes are invalid.
In case of Grid Engine "DRMAA_PS_FAILED" is returned as the
defectiveness
of these pathes at the execution machine can't be determined before the try to start the job.
Regards, Andreas
participants (2)
-
Peter Troeger -
Rajic, Hrabri