Description of problem: accounting groups are supposed to be case insensitive, but they are only working in lower-case. Steps to Reproduce: define groups A and B: +AccountingGroup="A.user" -> FAIL +AccountingGroup="a.user" -> SUCCESS Expected results: either case should work correctly
Created attachment 446438 [details] test for submitted fix (or bug repro) README file describes how to run test and what to expect if fix is working, or for bug repro.
Pushed a fix for this bug to V7_4-HFS-branch. Added case folding to group names pulled off submitter ads so that they match up properly with group names pulled from GROUP_NAMES.
Created attachment 451391 [details] Negotiator log Tried to with: condor-7.4.4-0.16 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. 2. see running jobs $ condor_q -run -l | grep AccountingGroup | sort | uniq -c 2 AccountingGroup = "a.user" 2 AccountingGroup = "A.user" 1 AccountingGroup = "b.user" 2 AccountingGroup = "B.user" The number of running processes are not OK. The negotiator still distinguish "a.user" and "A.user".
> The number of running processes are not OK. The negotiator still distinguish > "a.user" and "A.user". The log output shows it negotiating with both a.user and A.user against group "a" (and similarly group "b), which indicates that the case insensitivity is operating correctly. The actual value of AccountingGroup in the job ads is *not* case folded, which is why you see both a/A and b/B in the condor_q query. I notice that the negotiator only saw 16 slots when it entered its cycle, which is why you are seeing only 4 slots allocated to A/a and 3 slots for B/b. (I assume you were expecting 5 slots for A/a and 4 slots for B/b). My guess is the system just needs to spool up a bit longer so it sees all 20 slots.
OK, I didn't notice that the whole pool is not up, my bad. And I understand that it could be OK for job classads that there are both "a" and "A", but I still think that something is wrong because 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 I expect it should show that group "A" ("a") uses 5 resources.
> when I list condor_userprio > (classads from negotiator) it still distinguish group "A" from group "a". This is a separate bug in accountant and/or userprio. I logged a new bz for it: https://bugzilla.redhat.com/show_bug.cgi?id=640326
The negotiator correctly count number of slots per group. New bug 640326 was created for correct showing of groups by condor_userprio. Tested with (version): condor-7.4.4-0.16 Tested on: RHEL5 x86_64,i386 - passed RHEL4 x86_64,i386 - passed >>> VERIFIED