[gold-users] Projects and accounts

Michael Sternberg sternberg at anl.gov
Tue May 26 17:03:31 MDT 2009

On May 26, 2009, at 11:33 , Scott Jackson wrote:
> Michael Sternberg wrote:
>> (1) Are project hierarchies implemented?  (I'm using Gold-
> Account hierarchies exist, not project hierarchies, per se. However,  
> this amounts to the same thing. For example, you could create two  
> projects, A and B, then create an account for each of them (a pool  
> of resource credits). Then you could link the accounts as parent and  
> child. This allows for the delegation of management  
> responsibilities, the establishment of automatic rules for the  
> distribution of downstream resource credits, and the option of  
> making higher level credits available to lower level accounts.

That's a lot of possibilities, but I'm lost how to get started: what  
tack would I have to take to subordinate accounts?

>> (2) [..]
>> How does Gold handle a project with several accounts. i.e., how is  
>> an  appropriate account selected from a machine/project/user tuple?
> Gold sorts them by expiration time and generality. First and  
> foremost, Gold will use the credits that expire earliest, then, as a  
> second level differentiator, it will sort them such that accounts  
> which are more general are used last. For example, an account valid  
> for just scottmo or the specified machine, will be chosen before an  
> account that is a catchall for MEMBERS (more general) or ANY (most  
> general). Let me know if you would like more detail and I can dig up  
> an email I sent someone earlier who wanted to know the precise  
> algorithm.

Thanks, that's quite clear - I'd use only credit limits, not  
allocations for the catch-all, which never expire, and thus are  
considered last.  Other accounts in a Project (= Department) are user- 
exclusive, thus 'more specific first' is what effectively occurs,  
which is *perfect* for the organization I have in mind.

>> I wanted to create an organizational structure as follows:
>>   - Physical department -> Project D
>>   - Project D will have an intrinsic Account -> DA0
>>     This will be a fallback/testing account.
>>   - Physical department has Staff -> Users U1, U2, ...
>>     I give those users accounts under Project D -> DA1, DA2, ...
> Does this mean you create the accounts with User=MEMBERS (allowing  
> the users to be implied from the user members of Project D), or that  
> you create the accounts with Users=U1,U2,U3 explicitly (basically  
> ignoring their project affiliation)? I assume you mean the former.

Thanks! - I found that I user accounts U<n> need "-u user"; otherwise,  
"gbalance -u user" and "glsaccount -u user" list *all* accounts in the  
"user" or "staff" project, not just the catch-all and the user's own,  
and reservations/charges go against the time-selected account, which  
would mostly be that of the wrong user.

Actually, I started with already existing user-specific accounts and  
projects and migrated the accounts like this:

     gchaccount	--addUsers U1 --delUsers MEMBERS --addProjects users  - 
a  <U1id>

After prior reservations are expired, I'll do:

     grmproject U1

> Ahh, I see. We'd have to set it up to see how well this works.  
> Account hierarchies, although implemented, are little used and this  
> was not their primary purpose (to be used as an umbrella for  
> reporting). I think there is a good chance it will work for  
> gstatement and gbalance. I'm not at all certain about gusage.

Not even sure if I need hierarchies.  I can now do:

     gbalance -p staff
     gbalance -p user

Those act basically as filters to distinguish the two people groups,  
which have different privileges and reporting requirements.  There is  
no "total" row, but that is trivial to compute when needed for reports.

This does the right thing, showing only (1) the personal account, (2)  
the users or staff account, and (3) any proposal-based accounts/ 

     gbalance -u <username>


is not as long as it used to be, and contains only users, staff, and  
proposal-based projects (those have -u MEMBERS, and "gusage" works  
well there.)  The output of "glsproject" is *wide* because of the  
Users column for projects "users" and "staff" is, but that's not a  
problem as it can be suppressed using --show.

I'll watch the logs and transactions.  I have long jobs with a low  
turnover rate, but things look good so far.

With best regards,

More information about the gold-users mailing list