[gold-users] possibility to have a one-to-many relationship between allocation and projects?

ingmar ingmar at ucar.edu
Wed Jun 23 10:00:05 MDT 2010


Scott,
I have included a diagram to hopefully make the business process a 
little mor clear.
Thanks,
-ingmar
On 06/22/2010 05:03 PM, Scott Jackson wrote:
> Hi Ingmar,
>
> ingmar wrote:
>    
>> Hello,
>> I was wondering if anyone might have an idea on this one?  Gold supports
>> the idea of accounts having many allocations, and a project having an
>> allocation if it has just one account.
>>      
> Technically, a project does not have allocations. Only accounts have
> allocations. Because we believed that some sites would like to think of
> projects as having allocations (credits) directly, we created a few
> mechanisms to simplify the perceived relationships so it would seem like
> funds were being associated directly with the projects. In reality, what
> we did was to enable by default a configuration parameter called
> account.autogen which, if enabled, would automatically create a single
> account each time a new project was created. Additionally, we added a
> "-p" option to gdeposit so that you could believe that you were
> depositing into a project. In reality, it simply looked up the accounts
> that were associated with the specified project, and if there was only
> one, it would use that account.
>
> So to be precise -- Accounts are the only things that have allocations.
>
>    
>>    The hierarchy seems to be
>> Project ->  account(s) where each account can have one or more
>> allocation.
>>      
> The hierarchy really is more like:
>
> An Account is associated with one or more Projects, Users, Machines and
> Allocations.
>
> As you stated, each account can have one or more allocations. It can
> also be associated with more than one Project...
>
>    
>> It is also possible to have an account with a child account
>> and then allocations associated to the child account.
>>      
> I assume you are talking about nested accounts. Yes.
>
>    
>>    We have a current
>> business model where a division within the organization is
>> allocated/deposited a certain number of computing units.  This
>> allocation is then divided amongst different projects and in turn
>> accounts related to the projects.  It is nearly like the hierarchy
>> supported by Gold is 'turned upside down'.  My management wants to know
>> if this sort of business model could be supported by Gold?
>>      
> I think so, but I will have to have you explain it further. Please give
> a very simple example that illustrates the concept for a small number of
> accounts/projects/allocations. I think I understand the general idea
> (university A has 100 credits, subdivided with 50 going to arts and 50
> to sciences, and of the 50 to sciences, we have 10 that actually go to
> each of 5 different science departments (physics, biology, chemistry,
> and so forth). When you say the allocation is divided, how does this
> differ in actual behavior from actually putting the credits directly in
> the leaf accounts (biology, chemistry, etc)?
>
>    
>>    After seeing
>> the default hierarchy I would say no, not even with modification to the
>> database?  Our business model is counter to one of the fundamental
>> concept on which Gold is built?  I am thinking without a large amount of
>> code modification to Gold, this business model could not be supported?
>> Any thoughts or comments from other sites and their implementations?
>> Thanks,
>> -Ingmar Thompson NCAR
>> ____________________
>>      
> Thanks,
>
> Scott
>
>    
>> ___________________________
>> gold-users mailing list
>> gold-users at supercluster.org
>> http://www.supercluster.org/mailman/listinfo/gold-users
>>
>>      
> _______________________________________________
> gold-users mailing list
> gold-users at supercluster.org
> http://www.supercluster.org/mailman/listinfo/gold-users
>    

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PAN_concept_for_allocations.pdf
Type: application/pdf
Size: 19700 bytes
Desc: not available
Url : http://www.supercluster.org/pipermail/gold-users/attachments/20100623/4bdb5125/attachment-0001.pdf 


More information about the gold-users mailing list