[gold-users] Projects and accounts

Scott Jackson scottmo at clusterresources.com
Tue May 26 18:30:13 MDT 2009


Michael Sternberg wrote:
> On May 26, 2009, at 11:33 , Scott Jackson wrote:
>> Michael Sternberg wrote:
>>> (1) Are project hierarchies implemented?  (I'm using Gold-2.1.8.1)
>>>
>> 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?
>
Here is a sample narrative I just ran on my test system.

[scottmo at keko log]$ gmkproject myparent --createAccount=True
Successfully created 1 Project
Auto-generated Account 75
[scottmo at keko log]$ gmkproject mychild --createAccount=True -u scottmo
Successfully created 1 Project
Auto-generated Account 76
[scottmo at keko log]$ gdeposit -a 75 -z 10000
Successfully deposited 10000 credits into account 75
[scottmo at keko log]$ gdeposit -a 76 -z 100
Successfully deposited 100 credits into account 76
[scottmo at keko log]$ goldsh AccountAccount Create ShowUsage:=True
<Request action="Create">
    <Object>AccountAccount</Object>
    <Set name="Account" [op="Assign (Assign)"]>{Parent Account Id}</Set>
    <Set name="Id" [op="Assign (Assign)"]>{Child Account Id}</Set>
    <Set name="DepositShare" [op="Assign (Assign)"]>{Integer Number} 
(0)</Set>
    [<Set name="Overflow" [op="Assign (Assign)"]>True|False (False)</Set>]
    [<Option name="ShowHidden">True|False (False)</Option>]
    [<Option name="ShowUsage">True|False (False)</Option>]
</Request>

[scottmo at keko log]$ goldsh AccountAccount Create Account=75 Id=76 
DepositShare=50 Overflow=True
Successfully created 1 AccountAccount
[scottmo at keko log]$ gbalance -u scottmo
Id Name                Amount   Reserved Balance  CreditLimit Available
-- ------------------- -------- -------- -------- ----------- ---------
75 myparent               10000        0    10000           0     10000
76 mychild                  100        0      100           0       100
[scottmo at keko log]$ gdeposit -a 75 -z 1000
Successfully deposited 100 credits into account 75
75 myparent               10500        0    10500           0     10500
76 mychild                  600        0      600           0       600
# Notice how half (500) went to the child account (76), when put into 
the parent account (75) because of a DepositShare of 50
[scottmo at keko log]$ gcharge -u scottmo -p mychild -m colony -P 1 -t 1000 
-J job.1234
Successfully charged job job.1234 for 1000 credits
[scottmo at keko log]$ gbalance -u scottmo
Id Name                Amount   Reserved Balance  CreditLimit Available
-- ------------------- -------- -------- -------- ----------- ---------
75 myparent               10100        0    10100           0     10100
76 mychild                    0        0        0           0         0
# Notice how it first took it from the child, then slurped the rest from 
the parent (because Overflow was set to True)

>>> (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.
>

I'm a little confused, but it sounds like you do want some of the 
accounts (the ones that start with cap U), to be associated with a 
single user only, instead of to a project with multiple users. If so, 
then it sounds like you are on the right track. Generally, people create 
projects, add multiple users to the project, then associate the account 
with the project, leaving the Account User as MEMBERS so they can 
control the account access via the project-to-user association. It 
appears you have something else in mind and that you are able to 
accomplish it now? If so, great. That's part of the Gold design, to 
allow many flexible usage scenarios and not coerce people into what is 
considered the norm by others.
> 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
>     ...
>
Yes, I think it appears you are doing it as I imagined -- you want your 
accounts to be per-user. Great. It looks like you are doing it right for 
this.

>> 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/projects:
>
>     gbalance -u <username>
>
> Further,
>     glsproject
>
> 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.
>
Excellent. I'm glad it's coming together for you!

Scott

>
> With best regards,
> Michael



More information about the gold-users mailing list