[DRMAA-WG] What information should JobInfo provide ?

[Peter Tröger]

> As you indicated, Peter, it is not as easy as it sounds to add all job template attributes
> to the job info object. As mentioned before I think in most systems you can change the
> submission attributes after submission (in Grid Engine we have qalter, JSV, job classes,
> sge_request files, the -@ parameter, path aliasing) therefore we should be conservative and not 
> specify that the submission parameters in job info needs to match 100% the job template.

This is not the case so far, so everything is fine from this perspective.

> different, probably because of a different mount point. In UGE we have 
> something called path aliasing, which is done by the system transparently
> to the user. Now which output path would be correct?

A similar argumentation would hold for Condor.

> When the job template output path is right, then the question 
> is if it is catchable by all systems in a general way with job status calls?
> When the real output path is right then the question is do we get that one
> for all systems? I don’t think we can specify which one is the right on 
> DRMAA level hence we would need to make all of them optional or implementation
> specific. Hence the implementation specific approach seems more 
> natural for me.

I agree to Andre, this sounds reasonable.

> Due to the fact that we have already a method for returning the job template,
> and in order to have small consistent set of attributes in job info, I 
> would really not go the way to do such a major change.
> 
> Why I added this *job name* request in the job info object is because
> the job name (rather then other attributes) is probably the most 
> natural attribute of a job. In Univa Grid Engine you can do a lot of 
> useful things with it: defining job dependencies (or multi-job dependencies),
> using is for a grouped qstat etc. 

> - I can also live with the fact that job name is implementation specific
> but I really see the job name very basic and really worthy for job 
> filtering (especially when you want to group jobs like in UGE case).

Ok, since adding all job template attributes to JobInfo is overkill, I would be the best to have an objective decision criteria if a job template attribute should be in JobInfo or not. The above argumentation (‚useful for one product‘) is not good enough. Does anybody has a smart idea on this ?

If not, then I would vote for keep the spec as it is, meaning that JobInfo::jobName support becomes an implementation-specific feature of UGE. For the moment. If we have more than one implementation, than it is time to identify commonly added JobInfo attributes and adjust the „final recommendation“ spec accordingly.

Best regards,
Peter.