Am 28.04.2011 um 13:27 schrieb [email protected]: > Thank you Reuti, I think your suggestions gave me the right input! > But do I have to specify the "global" host in any specific way? qhost lists > global as a host, but if I try to replace > > $ qconf -mq cloud.q > > ... > hostlist @my_hostgroup localhost > ... > > with > > $ qconf -mq cloud.q > > ... > hostlist @my_hostgroup global > ... > > I get "unable to resolve host "global" ", which is absolutely clear, because > neither my dns nor my /etc/hosts know about "global".
Hehe - right: obviously I set up "0.0.0.0 global" already some time ago in /etc/hosts and forgot about it. -- Reuti > Regrads, > Stephan > > Quoting Reuti <[email protected]>: > >> Hi, >> >> Am 27.04.2011 um 18:38 schrieb [email protected]: >> >>>>> <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 > [email protected] > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
