Am 25.02.2012 um 00:19 schrieb S Joe:
> Thanks everyone for your help so far and sorry if I don't quite follow all
> the responses but I think I'm getting there. To review we normally run all
> of our jobs on the "compute" nodes in our cluster. But I have one job type
> "mascot" that I can run either on the compute nodes, or the interactive nodes
> (it just communicates with some windows boxes doing the actual work so it
> doesn't really take up any resources). As I understand it first off I can
> get rid of my mascot.q (great! one less queue). I then setup a mascot
> complex (requestable is TRUE). Only on my interactive exec
As BOOL or anything else?
> hosts I add the mascot complex = TRUE. I then setup in sge_request so that
> -l mascot=false. Now whenever a user submits a job it'll run in the hosts
> assigned to the various queues but not on the interactive host as mascot is
> always false. When I submit my mascot jobs use -l mascot, and these will
> then run on either compute or interactive hosts in the cluster/
Did you observe this, i.e. you set it nowhere to FALSE on the normal machines
and jobs requesting "-l mascot=FALSE" are still scheduled to some machines?
> I also tried playing around with the forced complex and I'm not sure I
> understand how it works. First I created a complex "mascot" as a BOOL,
> relation ==, requestable FORCED, default was FALSE because...well thats what
> it defaults to as you can values on non-consumables. I then added to the
> global host configuration the consumable/fixed attribute mascot with a value
> of false. When I submit a job using "qsub -w p -l mascot=true test.sh",
Because it's defined as "FALSE" on the global level.
> "qsub -w p -l mascot=false test.sh",
This should work (unless you have no machines where it's not set at all or set
to FALSE too).
> or "qsub -w p test.sh" I always get an error that are no suitable queues and
> that the job.
Because it's not requested at all, and you defined a FORCED complex on the
global level.
It's not overridden on an exechost level. Always both must be met (global +
exechost), which is impossible to be TRUE and FALSE at the same time.
For a <= relation still both need to be met, and the lower value will be the
constraint.
> does not request 'forced' resource "mascot" of host global. Remove the
> complex from the global host config and everything works normally. Adding
> the mascot complex to all of my exec hosts individually and trying the same
> submissions also results in the same message: job does not request 'forced'
> resource "mascot" of host x. I'm surprised because I thought setting
> requestable meant you had to request the resource and that's what I thought I
> was doing with the "-l mascot". It seems to be the same result when I assign
> the mascot complex to a queue. And for the record I don't have anything set
> in my $SGE_ROOT/$SGE_CELL/common/sge_request file.
If it's set to FORCED, you don't need any setup for jobs/exechosts not being
involved in mascot:
normal job: qsub job.sh
mascot job: qsub -l mascot job.sh
("-l mascot" is a shortcut for "-l mascot=TRUE") Nothing to be set up for the
FALSE condition, no sge_request, no assignment to exechosts where you defined
it before as FALSE, nothing on the global level.
http://www.bioteam.net/wp-content/uploads/2009/09/03-SGE-Admin-Config.pdf page
100.
-- Reuti
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
