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 |
Cc: |
Description
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=56]
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 URL: http://wiki.gridengine.info/wiki/index.php/EvaluationExpressionSupport * Summary: job resource request lacks OR operator Status whiteboard: Attachments: 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 alternatively. WORKAROUND: (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 mikeb@vitesse.com), 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 ' ' ','` xyz.sh (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 xyz.sh 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 ------- Workaround: 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. Stephan ------- Additional comments from petrjung Thu Jan 18 03:41:32 -0700 2007 ------- The new Feature document can be found and discussed on http://wiki.gridengine.info/wiki/index.php/EvaluationExpressionSupport ------- 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 ------- WORKAROUND: 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.
PJ-2007-01-19-0