Re: [Condor-devel] Some proposals regarding management of accounting groups and submitter names

[Erik Erlandson <eerlands@xxxxxxxxxx>]

On Fri, 2011-06-03 at 12:33 -0700, Erik Erlandson wrote:

> 
> With (a) and (b) in mind, I have proposals:
> 
> 1) Have AccountingGroup only include the actual accounting group.  The
> user name is taken from "Owner".  So, a job might be given using
> +AccountingGroup="a.b", with no user name.  Variations:  In the name of
> backward compatibility, support a new attribute that only uses group
> name (and deprecate AccountingGroup).  And/or, enforce that user portion
> of AccountingGroup matches "Owner".
> 
> 2) Add a new job attribute that denotes the job's submitter name.
> "JobSubmitter", or some such.  It would be essentially equivalent to
> (ifThenElse(AccountingGroup =!= undefined, AccountingGroup.Owner @
> omain, Owner @ domain))
> 
> 3) Implement a policy where jobs submitted with an undefined accounting
> group are placed on Hold.   This could be *mostly* accomplished at
> submission time, although there are also scenarios where a job's
> accounting group can evaporate due to a reconfig.  So periodic checking
> might be useful.  Doing this efficiently might warrant factoring of the
> accounting group data structure logic out of the accountant, depending
> on potential impacts of querying the negotiator.

Oh, and

4) If it will remain possible for jobs to be running under an acct group
that is different than the value of AccountingGroup, perhaps it becomes
the accountant's job to make sure the value of JobSubmitter is in sync
with what it assigned as the actual accounting group.