[GE users] Share trees

templedf dan.templeton at sun.com
Wed Jul 1 21:29:16 BST 2009


Sounds like it will work to me.

Daniel

jagladden wrote:
> Daniel,
>
> Thanks for responding.  I think I have this setup correctly now, but 
> just for review, here is what I have done.  I have created two projects:
>
> [gladden at bonanza turecek]$ qconf -sprjl
> core_project
> noncore_project
>
> and access to each project is restricted by an ACL like this:
>
> [gladden at bonanza turecek]$ qconf -sprj core_project
> name core_project
> oticket 0
> fshare 0
> acl core_userset
> xacl NONE
>
> and:
>
> [gladden at bonanza turecek]$ qconf -sprj noncore_project
> name noncore_project
> oticket 0
> fshare 0
> acl noncore_userset
> xacl NONE
>
> I also created a share tree to assign 80% and 20% shares to the two 
> projects respectively.  It looks like this:
>
> [gladden at bonanza turecek]$ qconf -sstree
> id=0
> name=Root
> type=0
> shares=1
> childnodes=1,2
> id=1
> name=core_project
> type=1
> shares=8000
> childnodes=NONE
> id=2
> name=noncore_project
> type=1
> shares=2000
> childnodes=NONE
>
> Finally, for each user I have assigned one of the two projects as the 
> default and also include that user in the ACl for the respective 
> project.  For example, for user "gladden" I have:
>
> [gladden at bonanza turecek]$ qconf -suser gladden
> name gladden
> oticket 0
> fshare 0
> delete_time 0
> default_project core_project
>
> and for the ACL I have:
>
> [gladden at bonanza turecek]$ qconf -su core_userset
> name    core_userset
> type    ACL DEPT
> fshare  0
> oticket 0
> entries 
> gladden,earnshaw,ketcham,adriana,akey7,ebadaeva,isborn,jhung,winco, \
>         
> kaynp,xsli,yongf,fischer4,tammien,zyguo,prezhdo,yuriyp,atchung,cmoss, \
>         nuonuo,xiaohong
>
> User "gladden" is NOT included in the ACL associated with the other 
> project.  If I understand what I have done, the result is that jobs 
> for user "gladden" will, by default, execute as members of 
> "core_project", and that the user cannot really change this because he 
> does not have access to any other projects.
>
> Does this look correct?
>
> James Gladden
>
> templedf wrote:
>> Of course, now that I look at it a little more closely, the share tree I 
>> suggested isn't valid because the default user is present twice in the 
>> same project ("no project" in this case).  More importantly, how should 
>> Grid Engine tell to which branch a job should belong?  To really get the 
>> behavior you want, you're going to have to use projects or enumerate the 
>> users in each group explicitly.  There's an open RFE to get Grid Engine 
>> to use external directory services, so we're well aware of the issue.
>>
>> Daniel
>>
>> templedf wrote:
>>   
>>> Don't forget about the default user.  You can do what you want with a 
>>> share tree that looks like this:
>>>
>>> /=1
>>> /group1=20
>>> /group1/default=1
>>> /group2=80
>>> /group2/default=1
>>>
>>> Daniel
>>>
>>> jagladden wrote:
>>>   
>>>     
>>>> I'm want to set up a share tree policy such that shares are assigned to 
>>>> groups of users - specifically something like 80% of the shares to the 
>>>> "core" user group and 20% of the shares to the "non-core" user group.  
>>>> However, as near as I can figure out, a node or leaf in a share tree 
>>>> must be associated with an sge "user" or "project:, not a "department" 
>>>> of unix group.  If I understand this correctly, the only kind of user 
>>>> group I can use in this context is the "project".  If this be the case, 
>>>> then do I somehow need to force and association between users and 
>>>> projects?  Am I on the right track here?
>>>>
>>>> James Gladden
>>>>
>>>> ------------------------------------------------------
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=204716
>>>>
>>>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
>>>>
>>>>     
>>>>       
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=204719
>>>
>>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
>>>
>>>     
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=204760
>>
>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
>>
>>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=204851

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list