[Condor-devel] RFC: increasing the sanity of accounting group notation

[Erik Erlandson <eje@xxxxxxxxxx>]

For ticket #2728 - "RFE: a 1st-class accounting_group 'command' for
submit files"
https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2728

I'm considering the following solution:

1) condor_submit will support the following new commands:

# This will *only* be the group name, not including username:
accounting_group = <groupname>

# this is the username portion of the acct grp entry, and will now
default to Owner:
accounting_group_user = <username>

2) When "accounting_group" is used, there will be a new attribute on the
job classad:
# this will hold user name, defaulted or otherwise:
AccountingGroupUser
# this will hold only group name:
AccountingGroup

3) A new delimiter will be supported between group and user, which I
propose to be colon ":"

4) The accountant will always use this new delimiter, and construct its
entries as <group>.<subgroup>:username

5) When the negotiator/accountant encounters a job ad with
AccountingGroup, but *no* AccountingGroupUser attribute, it will assume
it is in 'legacy' mode, and that AccountingGroup also includes the
username, as it currently does.

6) (proposed by TJ) when there is no AccountingGroupUser (legacy-mode),
the accountant will alter its current internal parsing logic so that it
stops consuming group/subgroups when it hits a component that does not
map to subgroup, so for example, if AccountingGroup holds
"physics.lab.erik.erlandson", then it will consume defined
group/subgroups "physics", "lab" and then interpret "erik.erlandson" as
the username, since there is no subgroup "erik."  (internally, it would
then construct entry physics.lab:erik.erlandson using new ":" delimiter)

Adopting (6) would replace the current behavior when the accountant
encounters a subgroup that doesn't exist, however I think (6) enables
some legacy-mode support for usernames with "." in them which is a more
useful behavior than the current behavior of just assigning the
most-specific group/subgroup that matched, and issuing a warning.

Supporting "accounting_group_user" means that username technically
remains on the honors system.  Actively enforcing AccountingGroupUser ==
Owner == 'login username' is an idea that could be cleanly filed as a
separate ticket, if there is any interest.