[DRMAA-WG] maxSlots attribute
daniel.templeton at oracle.com
Tue Mar 23 12:35:37 CDT 2010
As long as the MonitoringSession::drmsQueueNames is nothing more than an
opaque set of strings that are the valid values for
JobTemplate::queueName, I can live with it. I can see where that would
be useful for a portal. I thought, however, that we had come to the
conclusion previously that portals and user interfaces were not really
our target applications. (Anyone remember what feature spawned that
conclusion?) I thought that DRMAA was specifically focused on
applications integrating with clusters. If so, a list of opaque strings
By the way, you'll also have to give a little thought to reconciling the
1:1 queue/host model with the 1:n and n:m models, as far as identifying
them in a list goes.
On 3/23/10 10:27 AM, Peter Tröger wrote:
>> 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.
More information about the drmaa-wg