No subject

Wed Jan 12 20:38:46 GMT 2011

#define MSG_JOB_MOD_SOFTREQCONSUMABLE_S  _MESSAGE(33307, _("denied: soft
requests on consumables like "SFQ" are not supported"))

Is there any reason behind enforcing this? If so how can we use soft requests.

qsub -soft -l test=0.1 uptime
Unable to run job: denied: soft requests on consumables like "test" are not

-----Original Message-----
From: templedf [mailto:dani... at] 
Sent: Wednesday, July 14, 2010 7:55 PM
To: use... at
Cc: svibhore
Subject: Re: [GE users] Creating a Soft consumable resource

The qsub -soft switch with a consumable is what you want.  If you assign 
1 of your consumable to every machine and then request it with -soft, 
the scheduler will try to put only one per machine, but if it runs out 
of machines, it will ignore the consumable.


On 07/14/10 04:33 AM, svibhore wrote:
I have a scenario where I want to create a resource which should be used
( ideally) one per host but if all the resources are used( i.e all the
hosts have job using this consumable) the jobs should not fail and get
scheduled on any host.

In a typical hard resource the jobs would fail if all the hosts have one
job running on them, and in soft resource I cannot limit the number of
jobs getting scheduled on the host( which will be limited by number of

This will achieve two things for me, first the jobs gets distributed on
all host as one job per host and secondly this will guarantee that jobs
would not fail even if all the hosts have a job running on them.

Ideas ?



To unsubscribe from this discussion, e-mail:
[user... at].


Notice from Univa UD Postmaster:

This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This message has been content scanned by the Univa UD Tumbleweed MailGate.



To unsubscribe from this discussion, e-mail: [users-unsubscribe at].

More information about the gridengine-users mailing list