Validator could reject "invalid" jobs before they get passed to a scheduler on the systems which have a job filter present. I do not know if it is possible to make all the DRM systems behave equally in this case, since the point of failure could happen at different stages of job submission/execution. I will put it on the agenda. Hrabri
-----Original Message----- From: owner-drmaa-wg@ggf.org [mailto:owner-drmaa-wg@ggf.org] On Behalf Of Peter Tröger Sent: Thursday, March 23, 2006 3:00 PM To: Ruben Santiago Montero Cc: DRMAA Working Group Subject: Re: [drmaa-wg] DRMAA TEST SUITE
Our proposal is to remove the call of drmaa_wifaborted() for ST_INPUT_FILE_FAILURE / ST_ERROR_FILE_FAILURE / ST_OUTPUT_FILE_FAILURE. The drmaa_wait() call does not hurt (since all submitted jobs must be waitable), but the crucial part is the testing for the result of drmaa_synchronize(). After this change, I would expect the test cases to be successful also on your system. In case of malicious input / output / error files, the DRMAA implementation would only be expected to state a job failure. This should work for all GridWay-supported systems, right ? Could you accept this proposal ?
Sure. It make sense for me also.
There is also a validator in the state diagram (Section 2.6). I am just wondering if a DRMAA implementation could just reject the jobs in these tests at submission with a DRMAA_ERRNO_DENIED_BY_DRM.
The spec is unclear here, since the description of the input / ouput / error parameters demands a particular job state - DRMAA_PS_FAILED. You can only have a job state when you have a job id. YOu can only have a job id when drmaa_run() was successfull. I really would like to have the opportunity of DRMAA_ERRNO_DENIED_BY_DRM also in this case, but then we have to relax the description of the according job template attributes.
Sounds like another issue for the next phone call. Hrabri ?
Regards, Peter.