Red Hat Bugzilla – Bug 740774
Condor doesn't run jobs with real number in RequestMemory classad
Last modified: 2013-03-06 13:39:08 EST
Created attachment 524573 [details] logs, configuration and submit file Description of problem: Machine with DynamicSLots feature: I submit this job and it works: Universe=vanilla Iwd=/tmp Requirements=(FileSystemDomain =!= UNDEFINED && Arch =!= UNDEFINED) Executable=/bin/gawk Arguments="BEGIN{arr[-1]=0;for(i=0;i<11;i++){arr[i]=arr[i-1]systime()}}" queue If I put there positive integer value for RequestMemory, for example RequestMemory=1100 it works. With RequestMemory=(11*200.0)/2 or RequestMemory=1.0 it doesn't work. If I try this on machine without dynamic slots, it works and all submit examples above are matched and finished. Version-Release number of selected component (if applicable): condor-7.6.4-0.4 How reproducible: 100% Steps to Reproduce: 1. set up condor and dynamic slots 2. submit job with real value in classAd RequestMemory 3. watch logs and "condor_q -bet" output Actual results: It doesn't match jobs with real value in RequestMemory for nodes with DynamicSlots. Expected results: It will match jobs with real value in Request* classAds for nodes with DynamicSlots.
Same issue occurs for request_cpus and request_disk. The start is evaluating the attributes as integers. That evaluation is strict, so a RequestCPUs=2.0 evaluates as real(2.0) and the EvalInteger call in command.cpp fails. This is evident from the StartLog by looking at the "Match requesting resources: cpus=X memory=Y disk=Z%" line, it won't reflect the actual request. Options here are to - 0) Make the Startd more forgiving, let it coerce to an integer value and run the job 1) Keep the strict behavior but report a fatal error on the job, putting it on hold 1.1) Also have condor_submit attempt validation, necessarily incomplete as Request* expression may reference slot attributes In any event, the Startd should be more verbose about what it is doing in these situations. Bonus - is this a change in semantics between old and new ClassAds?
Ironically it is the schedd that rejects b/c. job_ad->EvalInteger(ATTR_REQUEST_MEMORY, match_ad, memory) fails. Update is to have EvalInteger cast where possible.
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: C: Submitting a job with RequestMemory equal to a floating point number. C: The job would not run. F: Update classads to cast the evaluation of RequestMemory to be equal to an integer. R: The job runs successfully.
Tested on RHEL 5.9/6.4 x x86_64/i386 with condor-7.8.7-0.5 and ti works. -->VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0564.html