[DRMAA-WG] maxSlots attribute

[Peter Tröger]

> As I said in the email I just wrote, I'm willing to be convinced of  
> the
> value of adding queues to the job submission side of things.  I am,
> however, fundamentally opposed to adding queues to the monitoring  
> side.

I will heavily insist on queue support in DRMAAv2, This is a long  
demanded feature, which also popped up again in the survey.

>  The various concepts of queues are too different for that to make any
> sense.  There is absolutely no way we will be able to model both LSF  
> and
> SGE queues in a way that is abstract enough to be consistent and still
> specific enough to be meaningful and accurate.  We'll talk on the next
> call. :)

The intention of the current model is that JobTemplate::queueName and  
MonitoringSession:: drmsQueueNames act as counterparts. DRMAA would  
promise that all strings that show up in MonitoringSession::  
drmsQueueNames are valid input for JobTemplate::queueName. Nothing more.
The use case are DRMAA-based portals and command-line applications.  
The interpretation of what a queue is can be provided by the library  
implementation - at the end, the user anyway has to reason about the  
meaning of queue names.

We could relax the conditions so that other values are also allowed in  
JobTemplate::queueName. This would allow MonitoringSession::  
drmsQueueNames to return nothing in SGE. This must be anyway possible  
- Condor has no queue concept at all.

I could also agree to remove MonitoringSession:: queueMaxWallclockTime  
and  MonitoringSession:: queueMaxSlotsAllowed, since these two  
attributes are the ones that demand a particular understanding of what  
a queue is.

Best,
Peter.