Description of problem: condor_userprio appears to be improperly distinguishing between "a.user" and "A.user" Steps to Reproduce: configuration: NEGOTIATOR_DEBUG = D_FULLDEBUG | D_MATCH SCHEDD_INTERVAL = 15 NEGOTIATOR_USE_SLOT_WEIGHTS = FALSE NUM_CPUS = 20 GROUP_NAMES = A, B GROUP_QUOTA_DYNAMIC_A = 0.25 GROUP_QUOTA_DYNAMIC_B = 0.2 GROUP_AUTOREGROUP_A = FALSE GROUP_AUTOREGROUP_B = FALSE submit file: $ cat test.submit universe = vanilla cmd = /bin/sleep args = 5m +AccountingGroup = "a.user" queue 5 +AccountingGroup = "A.user" queue 5 +AccountingGroup = "b.user" queue 5 +AccountingGroup = "B.user" queue 5 Scenario: 1. submit jobs $ condor_submit test.submit Submitting job(s).................... 20 job(s) submitted to cluster 1. Actual results: when I list condor_userprio (classads from negotiator) it still distinguish group "A" from group "a". $ condor_userprio -l LastUpdate = 1286262730 Name1 = "b.user.eng.bos.redhat.com" Priority1 = 0.504585 ResourcesUsed1 = 2 ... Name2 = "B.user.eng.bos.redhat.com" Priority2 = 0.504585 ResourcesUsed2 = 2 ... Name3 = "a.user.eng.bos.redhat.com" Priority3 = 0.505067 ResourcesUsed3 = 3 ... Name4 = "A.user.eng.bos.redhat.com" Priority4 = 0.507183 ResourcesUsed4 = 2 ... Name5 = "A" Priority5 = 0.507183 ResourcesUsed5 = 2 ... Name6 = "B" Priority6 = 0.504585 ResourcesUsed6 = 2 ... Name7 = "a" Priority7 = 0.505067 ResourcesUsed7 = 3 ... Name8 = "b" Priority8 = 0.504585 ResourcesUsed8 = 2 Expected results: I expect it should show that group "A" ("a") uses 5 resources. Additional Info: See also: https://bugzilla.redhat.com/show_bug.cgi?id=632476 https://bugzilla.redhat.com/show_bug.cgi?id=617709
Updated accountant logic includes case folding for groups: V7_4-BZ619557-HFS-tree-structure
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Submission of accounting groups with multiple cases (e.g. "group" versus "Group" versus "GROUP"). Consequence: The accountant treated accounting groups as case sensitive, so different cases were incorrectly managed as different groups, which shows up in condor_userprio and also affects internal use of group priorities. Fix: The accountant was updated with proper case-folding logic so that accounting groups are case insensitive. Result: Accounting groups can be submitted using any case, and are correctly treated as case insensitive by the accountant.
Tested on RHEL5.6/4.9 x x86_64/i386 with condor-7.4.4-0.17 and it is case sensitive.
Tested on RHEL5.6/4.9 x x86_64/i386 with condor-7.4.5-0.6 and it is case insensitive. --> VERIFIED
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,11 +1 @@ -Cause: +Previously, the accountant treated accounting groups as case sensitive when accounting groups with multiple cases (e.g. "group" versus "Group" versus "GROUP") were submitted. Due to this behavior, different cases were incorrectly managed as different groups, which shows up in condor_userprio and affects the internal use of group priorities. With this update, the accountant uses the correct case-folding logic so that accounting groups are case insensitive. Now, accounting groups can be submitted using any case, and are correctly treated as case insensitive by the accountant.-Submission of accounting groups with multiple cases (e.g. "group" versus "Group" versus "GROUP"). - -Consequence: -The accountant treated accounting groups as case sensitive, so different cases were incorrectly managed as different groups, which shows up in condor_userprio and also affects internal use of group priorities. - -Fix: -The accountant was updated with proper case-folding logic so that accounting groups are case insensitive. - -Result: -Accounting groups can be submitted using any case, and are correctly treated as case insensitive by the accountant.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0217.html