[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Condor-devel] Some proposals regarding management of accounting groups and submitter names
- Date: Fri, 03 Jun 2011 12:33:16 -0700
- From: Erik Erlandson <eerlands@xxxxxxxxxx>
- Subject: [Condor-devel] Some proposals regarding management of accounting groups and submitter names
There are a couple outstanding issues relating to the management of
accounting groups and submitter names that can cause confusion:
a) Consider this submitted acct group: +AccountingGroup="a.z.kilroy"
Firstly, it is possible that either part or all of the group "a.z" is
not actually defined in the config. The Accountant will helpfully map
it to the most-specific existing group (with a warning), however it
clearly can cause users to wonder what happened if they accidentally (or
deliberately) use an undefined group name.
Secondly, the user name "kilroy" is currently decoupled from Owner, or
any other "actual" user name -- the user who submits the job can put
anything in there.
b) The submitter name that a job runs under currently can be derived
either from AccountingGroup (if it is given) or Owner. There is not
any one job ad attribute that can be queried to answer "what submitter
name am I running under?"
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.