Am 08.04.2013 um 14:28 schrieb Tina Friedrich: > Hi Reuti, > > On 08/04/13 13:12, Reuti wrote: >> Hi Tina, >> >> Am 08.04.2013 um 11:16 schrieb Tina Friedrich: >> >>>>> is it possible to restrict access to a queue by anything but ACL or >>>>> project? A complex/resource would be a favourite. >>>> >>>> A forced boolean complex attached to a queue? >>> >>> Ah, no. Thought of that, but can't in this case; this would overall limit >>> access to the queue on this host group. Current right to it are >>> project/user based, and the behaviour shouldn't change - the whole problem >>> is that I'd like a setup like 'either this complex OR this user OR this >>> project' (and the bit with the complex seems to be exclusively AND :) ). >> >> Aha, now I see the point. A JSV could put some logic into it by an attached >> normal boolean complex to all queues: TRUE for the un-suspensible queue, >> FALSE for other queues. >> >> ALLOWED_USER=$(jsv_get_param USER) >> CMDNAME=$(jsv_get_param CMDNAME) >> >> if [ "$ALLOWED_USER" = "reuti" ]; then >> # Privileged users here. >> # Or don't attach anything, if it's not the default queue for them. >> jsv_sub_add_param l_soft highest=TRUE >> do_correct="true" >> else >> # Normal users here. >> if [ "$CMDNAME" = "NONE" ]; then >> jsv_sub_add_param l_hard highest=TRUE >> do_correct="true" >> else >> jsv_sub_add_param l_hard highest=FALSE >> do_correct="true" >> fi >> fi > > Unfortunately I don't think I can use a JSV either. It would solve the > problem nicely, yes; however, last time I looked into JSVs they just slowed > submission down too much - my cluster's got a slightly odd workload, in that > it's mainly used to run a lot of very quick jobs (runs with a one second > scheduling interval).
If the JSV is in Bash: true. Perl would be much better: https://blogs.oracle.com/templedf/entry/performance_considerations_for_jsv_scripts -- Reuti >> -- Reuti >> >> [Initially I thought of a FORCED boolean complex with: >> >> if it's a certain user/project => add the request for the boolean complex as >> a soft request >> is it any other user for an immediate job "$CMDNAME" = "NONE" => request the >> boolean as a hard request >> any normal user requests the complex for a batch job => remove it as it's >> not allowed >> >> but this is not working: soft requests are not considered as being FORCED. >> Somehow I think this is wrong.] > > Ah, yes. I remember running in to that one. I'd agree; this seems wrong. > > Tina > >>>>> Possible alternative - is there a way to set things up so that >>>>> interactive jobs aren't suspended via queue subordination (on a specific >>>>> hostgroup)? >>>> >>>> Only with a second queue without subordination - an RFE for a >>>> "suspendable" flag I had in mind too: >>>> https://arc.liv.ac.uk/trac/SGE/ticket/735 >>> >>> Yes, that would be quite nice to have really! >>> >>> Oh well. I think in this case, project it will have to be. Well, or queue. >>> Shame, I'd have liked to keep the projects users group (not workload) >>> centric (and I like to keep queue numbers down)! >>> >>> Tina >>> >>>> -- Reuti >>>> >>>> >>>>> Scenario is this - cluster with multiple (subordinate) queues; access to >>>>> the highest priority one is limited (both user and/or project, depending >>>>> on host group). Unfortunately, now also got an interactive job that >>>>> should not be suspended regardless of who's running it. Not quite sure if >>>>> they need to be in highest priority queue (might be the easiest). >>>>> >>>>> I could introduce a project for this I suppose; however, if there was a >>>>> way to solve it with a resource I'd prefer that. Any suggestions? >>>>> >>>>> Tina >>>>> -- >>>>> Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd >>>>> Diamond House, Harwell Science and Innovation Campus - 01235 77 8442 >>>>> >>>>> -- >>>>> This e-mail and any attachments may contain confidential, copyright and >>>>> or privileged material, and are for the use of the intended addressee >>>>> only. If you are not the intended addressee or an authorised recipient of >>>>> the addressee please notify us of receipt by returning the e-mail and do >>>>> not use, copy, retain, distribute or disclose the information in or >>>>> attached to the e-mail. >>>>> Any opinions expressed within this e-mail are those of the individual and >>>>> not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. >>>>> cannot guarantee that this e-mail or any attachments are free from >>>>> viruses and we cannot accept liability for any damage which you may >>>>> sustain as a result of software viruses which may be transmitted in or >>>>> with the message. >>>>> Diamond Light Source Limited (company no. 4375679). Registered in England >>>>> and Wales with its registered office at Diamond House, Harwell Science >>>>> and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> users mailing list >>>>> [email protected] >>>>> https://gridengine.org/mailman/listinfo/users >>>> >>>> >>> >>> >>> -- >>> Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd >>> Diamond House, Harwell Science and Innovation Campus - 01235 77 8442 >>> >>> -- >>> This e-mail and any attachments may contain confidential, copyright and or >>> privileged material, and are for the use of the intended addressee only. If >>> you are not the intended addressee or an authorised recipient of the >>> addressee please notify us of receipt by returning the e-mail and do not >>> use, copy, retain, distribute or disclose the information in or attached to >>> the e-mail. >>> Any opinions expressed within this e-mail are those of the individual and >>> not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. >>> cannot guarantee that this e-mail or any attachments are free from viruses >>> and we cannot accept liability for any damage which you may sustain as a >>> result of software viruses which may be transmitted in or with the message. >>> Diamond Light Source Limited (company no. 4375679). Registered in England >>> and Wales with its registered office at Diamond House, Harwell Science and >>> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom >>> >>> >>> >> >> >> > > > -- > Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd > Diamond House, Harwell Science and Innovation Campus - 01235 77 8442 > > -- > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not use, > copy, retain, distribute or disclose the information in or attached to the > e-mail. > Any opinions expressed within this e-mail are those of the individual and not > necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot > guarantee that this e-mail or any attachments are free from viruses and we > cannot accept liability for any damage which you may sustain as a result of > software viruses which may be transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and > Wales with its registered office at Diamond House, Harwell Science and > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
