Hi, Am 27.04.2011 um 18:38 schrieb srie...@ekp.uni-karlsruhe.de:
>>> <snip> >>> $ qconf -mq my.q >>> >>> ... >>> user_lists NONE >>> xuser_lists my_list >>> ... >>> >>> But instead of revoking qsub commands I can still submit jobs from user >>> "my_username". >> >> Adding something to xuser_lists will block user(s) to use this resource. But >> jobs from my_username should never ever being scheduled to this queue. This >> doesn't mean that you can't submit at all - the job will just hang there >> when there is no other queue. You can submit with "-w e" get an error when >> there is no suitable queue at all. >> > > Ok, now it makes much more sense to me. But how can I block a job from > execution, or even better, from submission, which is submitted to a certain > queue from a user which is on the blocklist? If the job is submitted to this > queue it should not end up in another queue. Is this possible? If you don't specify any queue at all, as this is not necessary in SGE, the job will automatically be scheduled to any queue the user is entitled to use - nothing to do on your side. If you want to use hard coded queues and forbid jobs to hang around for ever as they can't start in a requested queue: a) use "-w e" and it will throw an error (this could be added as a default request in $SGE_ROOT/default/common/sge_request) (man sge_request) b) define a JSV (job submission verfier) to make changes to the original submit options before it is forewared, i.e. route certain jobs from user to certain queues As b) can be put in user_lists/xuser_lists definition, this might not be the best option though. >>> Another thing I want to do right is that I want to be able to submit jobs >>> to a queue which has currently no execution hosts registered. >> >> Why do you want to do so? >> >> Although there are situations when you want to submit to a queue, the >> paradigm in SGE is to request resources and SGE will select an appropriate >> queue for you, which will fulfill the resource request. Submitting to a >> queue is more Torque-style. >> >> Can you rephrase the problem by requesting memory, walltime, diskspace, >> cores... or a complex having a certain value? Something like: >> >> $ qsub -l cpu_type=propeller job.sh >> > > The thing is, I want users to submit to a special queue "cloud.q". As soon as > there is need for new resources they will be added dynamically to GE. > Otherwise there will be no hosts. Afterwards they will be killed and > disconnected from GE. > I know, that GE is not intended to be used that way, but tests show that it > is capable of. And to reduce cloud usage, I want to restrict this queue. > I hope this makes thing clearer. What about a forced boolean complex. The complex must be defined beforehand and so users can submit: $ qconf -sc #name shortcut type relop requestable consumable default urgency #------------------------------------------------------------------------------------------ ... cloud cl BOOL == FORCED NO 0 0 $ qsub -l cloud job.sh which implies "cloud=TRUE". When you now add machines which should only be available for cloud jobs, define cloud=TRUE in the exechost defintion. You neither need a hostgroup, nor a dedicated queue this way. An non-cloud jobs won't run on these machines. Until such machines become available, the jobs will just wait. (If you add an arbitrary "localhost" or alike to the queue definition, they will even show up in `qhost`. An alternative may be the entry "global" which exists anyway.) -- Reuti -- Reuti _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
