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
-- 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.]
>>> 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
>
>
>
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
