[GE users] Share Tree Policy setup

Charu Chaubal Charu.Chaubal at Sun.COM
Tue May 24 01:39:24 BST 2005


Hi,

On May 23, 2005, at 5:05 PM, Mikael Johansson wrote:

>
> Hello Charu and All!
>
> On Mon, 23 May 2005, Charu Chaubal wrote:
>
>>> The cluster contains two cluster queues in addition to all.q; chem.q 
>>> and phys.q. Either has to be defined in the job script.
>
>> One question is: why do you have these two queues defined in the 
>> first place? What purpose do they serve that a single 'all.q' would 
>> not?
>
> Well, the cluster is shared by both chemists and physicists. Chemists 
> are by default allowed to run on only the part of the cluster financed 
> by the chemistry department, chem.q (or rather, @chemhosts) and vice 
> versa. There is also a difference between the nodes, the chem nodes 
> are faster and have more RAM and disk.
>

If you already have hostgroups defined, then actually you wouldn't need 
two queues,  You could just use all.q and have both hostgroups as part 
of its 'hostlist' (misnamed parameter, since it can include hostgroups 
as well).

If you have userlists defined for each department, then it even can 
become totally transparent to the user.  Simply set access permissions 
for each user group according to the hostgroup, eg, something like:
access_list	NONE,[@chemhosts=chemuserlist, at physhosts=physuserlist]

Then, only users in chemuserlist have access to the chemhosts, and 
likewise for physics.

Unfortunately, you cannot use userlists directly inside a share tree 
--- for that you'd need to add individual users to the, or else create 
two projects "chem" and "phys" and insert those into the share tree 
with desired shares set, and then use the userlists to create access 
permissions on those two projects.

Then, you'd have the share tree policy *and* restrictions on who can 
use what hosts, and it should be totally transparent to the end user.  
(Unless I've missed something ;^)

Regards,
	Charu


> The all.q is there for future purpouses (and because I wasn't sure I 
> could just delete it...), but for now the user is supposed to specify 
> which q to use.
>
>
>> 'qconf -help' will show all command lines options for setting 
>> everything by CLI.  You can look at this HOWTO for more info and some 
>> examples (note that it was written for 5.3, but mostly everything 
>> should still apply to 6).
>>
>> http://gridengine.sunsource.net/howto/scripting.html
>
> Thanks!
>
> Have a nice day,
>     Mikael J.
>     http://www.helsinki.fi/~mpjohans/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>
###############################################################
# Charu V. Chaubal				# Phone: (650) 786-7672 (x87672)
# Grid Computing Technologist	# Fax:   (650) 786-4591
# Sun Microsystems, Inc.			# Email: charu.chaubal at sun.com
###############################################################


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list