[saga-rg] Comments on the job API (revision 1.4)

[Graeme Pound]

Hi,

I have some comments on the job section of the Strawman API (revision 1.4).

Thanks
   Graeme



  -3.37 I do not understand the purpose of job_service.get_self() which 
returns a Job object.

  -3.38 I like the removal of the JobInfo and JobExitStatus objects from 
the API, and adding this information as attributes to Job. This 
streamlines the API, the concept of read only attributes also makes 
sense [to me] within the context of the Job object.

  -3.39 I like the simplification of the job_state enumeration. NB This 
is called 'state' in the SIDL and should be corrected to 'job_state'.

  -3.41 The separation of the JobService.submitJob() method into two 
methods JobService.createJob() [create the job object] and Job.run() 
[start the job] has not been seamless and there are several of 
conceptual and practical problems. This needs to be fine-tuned further. 
On many [all?] resource managers there is no separation between 
submitting a job to the resource manager and manually starting the job, 
this raises the following problem:
         - Job objects are identified via the job_id which is described 
as the  "job identifier as returned by the resource manager". 
Unfortunately since this information will only be available upon 
submission of the job (via Job.run()) this breaks the methods 
JobService.list() and JobService.getJob(). It is now impossible to 
manage an index of Job objects within JobService based upon the job ID.
         - What is the conceptual relationship between the JobService 
and the resource manager? At present this is a little confused in a 
couple of ways.
             #1 Should there be a one to one relationship between 
JobService instances and resource managers; i.e. should the resource 
manager endpoint be specified in the JobService constructor (or 
otherwise as an argument to JobService.createJob())?
             #2 The term JobService implies a close relationship to the 
resource manager. Previously JobService.submitJob() corresponded to 
communication with the resource manager. Now JobService.createJob() 
corresponds to the creation of instances of the Job class the JobService 
is acting as a factory. It may beneficial to rename JobService to 
JobFactory to clarify the relationship.

  -3.42 Should Job objects created by runJob() be added to the index 
managed by the JobService? Or in other terms, should JobService.runJob() 
be a Java 'static' method?