Could SDM help in this case? Sent from my iPad Hung-Sheng Tsao ( LaoTsao) Ph.D
On Apr 27, 2011, at 1:12 PM, Reuti <re...@staff.uni-marburg.de> wrote: > 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 _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
