Opened 19 years ago

Closed 8 years ago

#3 closed feature (fixed)

IZ56: job resource request lacks OR operator

Reported by: andreas Owned by:
Priority: normal Milestone:
Component: sge Version: current
Severity: minor Keywords: scheduling


[Imported from gridengine issuezilla]

        Issue #:      56               Platform:     All              Reporter: andreas (andreas)
       Component:     gridengine          OS:        All
     Subcomponent:    scheduling       Version:      current             CC:
                                                                                [_] uddeborg
                                                                                [_] Remove selected CCs
        Status:       REOPENED         Priority:     P3
      Resolution:                     Issue type:    FEATURE
                                   Target milestone: not determined
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
       * Summary:     job resource request lacks OR operator
   Status whiteboard:

     Issue 56 blocks:
   Votes for issue 56:

   Opened: Mon Sep 3 09:26:00 -0700 2001 

DESCRIPTION: The job submission lacks an OR operator allowing to specify
multiple combined resource request profiles (-l, -pe, -master, ...) to be used

(1) For sequential jobs a workaround can be to use the -q <qlist> option to
     explicitly specify the list of all alternatively suited queues.
(2) For parallel jobs alternative PE's can be requested by using wildcards in
     the -pe <pe-name> request. By creating different PE's with different
     queue_list it is possible to specify alternative assignments for the job.

SUGGESTED FIX: A new submit option -or could be used to separate between
alternatively suited combined resource request profiles. All scheduling relevant
submit options (-l, -pe, -master, ...) separated by a -or option must be matched
by a queue or by a set of queues for an assignment of the job.

   ------- Additional comments from joga Mon Jul 22 23:56:38 -0700 2002 -------
PROPOSAL FROM A GRID ENGINE USER (Michael Bakkenson, that shows an easy to use syntax:

I think it would be nice if it were possible to make more complicated
resource requests.  I am solving the multi-architecture problem by
building up a list of queues beforehand with multiple calls to
qselect, then specifying them with -q.

abc="`qselect -l arch=solaris64` `qselect -l arch=hp11`"
qsub -q `echo $abc | tr ' ' ','`

(there's probably a better way to do that..)

I think it'd be useful if requests like this were possible:

qsub -l '(arch=solaris64 || arch=hp11) && (speed=fast || speed=med)'
-soft -l speed=fast

i.e., you want 'fast', will take 'med' (but not 'slow') and can run on
solaris64 or hp11 (but not glinux)... or something.

   ------- Additional comments from andreas Thu Dec 11 07:14:49 -0700 2003 -------
With 6.0 use of wildcards with complex attributes
is supported. This can be used to request multiple resources and
extenuates urgency of or request.

   ------- Additional comments from andreas Thu Dec 9 05:21:27 -0700 2004 -------
Please note connection to "resource sets" use case as described with
issue #1391.

   ------- Additional comments from uddeborg Fri Apr 29 01:38:15 -0700 2005 -------
When doing this, don't forget the "not" operator.  It is not possible to use the
workaround for that.  For example, I can not choose queues on all machines
except AMD64 ones (arch!=lx24-amd64).  And then arch is an RESTRING, but it
still doesn't help.

   ------- Additional comments from sgrell Mon Dec 12 02:40:05 -0700 2005 -------
Changed subcomponent.


   ------- Additional comments from petrjung Thu Jan 18 03:41:32 -0700 2007 -------
The new Feature document can be found and discussed on

   ------- Additional comments from andreas Tue Mar 20 02:37:47 -0700 2007 -------
I'm reopening this as it specifically asks for logical "or" where different
kinds of resources can be requested. The 6.1 resource request enhancement merely
allows different values of a certain resource be requested. Although this can be
suited as a workaround in certain cases, but the problem isn't solved.

   ------- Additional comments from andreas Tue Mar 20 03:02:07 -0700 2007 -------
Both (1) and (2) above can solve the case, under the condition, that (a) the
requested queues have "lic1" and "lic2" configured in complex_values and (b) the
license amount is specified as default request with the consumable definition

#name  shortcut   type        relop requestable consumable !!!default!!! urgency
lic1   l1         INT         <=    YES         YES        1             0
lic2   l2         INT         <=    YES         YES        1             0

the obvious drawback of this workaround is, that either separate queues for
these resources must be specified or any job not depending on "lic1"/"lic2" must
exclude these default requests by using "-l lic1=0,lic2=0"

Change History (1)

comment:1 Changed 8 years ago by dlove

  • Resolution set to fixed
  • Severity set to minor
  • Status changed from new to closed


Note: See TracTickets for help on using tickets.