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.