Bug 632476

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