[drmaa-wg] DRMAA TEST SUITE

[Peter Tröger]

> Sorry, I do not agree. In the DRMS context, job life cycle comprises all the 
> job execution stages since the job enters the DRM system. In this sense, 
> whenever a job is submitted there should be a termination (either it actually 
> ran or not). I can give you an example, if you submit a job (qsub) and then 
> you kill it (qdel), it is obvious that the job terminated abnormally (it has 
> been killed), although the job never entered the running state.

This is one possible interpretation, I agree. The DRMAA spec is aligned 
to POSIX semantics here - it is only possible to have something 
terminated which was running (== executed) before.

> There is no relation between if the job terminated normally and if there is no 
> further information from the DRM. In the previous example (a job that has 
> been killed) could or could not be more information from the DRMS.  But in any 
> case, it is clear that the job terminated abnormally.
> 
> drmaa_wifexited description should concentrate in one aspect since there is no 
> obvious (or general) relation between job termination and getting further 
> information from DRM.

You are right. The main intention of drmaa_wifexited() is to tell you if 
additional information about the job execution ending is available. The 
final status of the job is provided by drmaa_job_ps(), and nothing else.

The confusion might eventually be solvable by a slight reformulation of 
the first sentences in the drmaa_wif...() descriptions, in order to 
avoid the word "termination". This would not lead to a change of semantics.

I have no good proposal - DRMAA group ?

>> ( Note: The testsuite assumes here that unusable input files are
>> detected by the DRM before the job starts. This  seems to be realistic,
>> since file staging operations are usually not part of the job execution.)
>>
> 
> I do not think so. Usually job preparation stages are part of the job 
> execution, for example:
...
> Therefore I suggest removing the ST_ERROR_INPUT_FAIURE, ST_ERROR_FILE_FAILURE 
> and  ST_ERROR_FILE_FAILURE from the official test suite. In the previous DRMs 
> at least, you can submit a job with output file /etc/passwd or an unusable 
> input file , the job is queued, runs and fails.

During the last phone call, the group went through the code. We agree to 
your impression that the 3 tests are currently not sufficient. The 
descriptions for "input / output / error stream" job template parameters 
says that an invalid value should result in the job state 
DRMAA_PS_FAILED - and nothing more. There is no description of what that 
means for drmaa_wif...() calls, but the testsuite expects a particular 
behavior. If you look at DRMAA section 2.6, it is clearly shown that 
DRMAA_PS_FAILED is possible both for queued and running jobs.

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 ?

BTW: Condor is one example for a system where the existence of input 
files is checked before the job is started. But at least your GRAM 
example convinced me that the opposite is also true ;-) ...

> Sure. The problem is that the code is not clear either. From DRMAA 1.0 C 
> bindings example:
...
> From this code it seems that a signaled job should end with a zero exited 
> value from wifexited (as if it did not terminate normally), as opposed to 
> your comments in the previous mails and the code in the DRMAA test suite.

You are right, as already said above. drmaa_wifexited() mainly indicates 
the availability of additional information.

Regards,
Peter.