[DRMAA-WG] maxSlots attribute
peter at troeger.eu
Tue Mar 23 12:27:04 CDT 2010
> As I said in the email I just wrote, I'm willing to be convinced of
> value of adding queues to the job submission side of things. I am,
> however, fundamentally opposed to adding queues to the monitoring
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
> 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.
More information about the drmaa-wg