Bug 833095 - total local resources per slot for dynamic slots is always zero
total local resources per slot for dynamic slots is always zero
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: condor (Show other bugs)
2.2
All All
medium Severity medium
: 2.3
: ---
Assigned To: Erik Erlandson
Lubos Trilety
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 10:56 EDT by Lubos Trilety
Modified: 2013-03-06 13:44 EST (History)
5 users (show)

See Also:
Fixed In Version: condor-7.8.4-0.1
Doc Type: Bug Fix
Doc Text:
Cause: local resource allocations not internally copied to slot-total data structure during dynamic slot instantiation Consequence: Values for local resource attribute TotalSlotXxx were reported as zeros on the classad Fix: Added proper data structure copy internally Result: Values for TotalSlotXxx are now reported consistently with standard TotalSlotCpus, TotalSlotMemory, etc.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-06 13:44:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Condor 3229 None None None 2012-09-13 13:56:26 EDT

  None (edit)
Description Lubos Trilety 2012-06-18 10:56:33 EDT
Description of problem:
The total per slot for the local resource has different behaviour than total per slot for cpus|memory|disk. The TotalSlotCpus shows number of used cpus for dynamic slots whilst TotalSlot[Local_Resource_Name] is always zero for dynamic slots.

Version-Release number of selected component (if applicable):
condor-7.6.5-0.15

How reproducible:
100%

Steps to Reproduce:
1. Repeat scenario in Bug 591521 look for TotalSlot[Local_Resource_Name] e.g. TotalSlotGpu
  
Actual results:
The value of TotalSlot[Local_Resource_Name] for dynamic slots is always zero.

Expected results:
The value of TotalSlot[Local_Resource_Name] for dynamic slots should be similarly counted as value for TotalSlotCpus|Memory.

Additional info:
Comment 1 Erik Erlandson 2012-09-13 19:31:03 EDT
REPRO:

Use the following configuration with a local 'gpu' resource configured:

NUM_CPUS = 2

# configure two 'gpu' resources:
MACHINE_RESOURCE_NAMES = gpu
MACHINE_RESOURCE_gpu = 2

SLOT_TYPE_1 = 100%
SLOT_TYPE_1_PARTITIONABLE = True
NUM_SLOTS_TYPE_1 = 1

Spin up the pool, and verify a single p-slot:

$ ccdump condor_status SlotType TotalSlotCpus Cpus TotalSlotGpu Gpu
Partitionable | 2 | 2 | 2 | 2

Submit a simple job that uses one cpu and one gpu:

universe = vanilla
cmd = /bin/sleep
args = 600
should_transfer_files = if_needed
when_to_transfer_output = on_exit
request_gpu = 1
queue 1

Once the job negotiates, you should see a new dynamic slot. The d-slot's value for TotalSlotGpu is zero. (we would like it to be the same as Gpu, that is 1):

$ ccdump condor_status SlotType TotalSlotCpus Cpus TotalSlotGpu Gpu
Dynamic | 1 | 1 | 0 | 1
Partitionable | 2 | 1 | 2 | 1

2012-Sep-13 18:24:49 by eje:
TEST:

to test fix, run the same repro described above. However, once the job negotiates, the value for TotalslotGpu on the dynamic slot should now be 1:

$ ccdump condor_status SlotType TotalSlotCpus Cpus TotalSlotGpu Gpu
Dynamic | 1 | 1 | 1 | 1
Partitionable | 2 | 1 | 2 | 1
Comment 2 Erik Erlandson 2012-09-14 16:52:19 EDT
I added this fix to UPSTREAM-7.9.0-BZ591521-local-machine-resources-rebased, Tim is merging and building
Comment 5 Martin Kudlej 2013-02-06 03:59:31 EST
Tested on RHEL 5.9/6.4 x i386/x86_64 with condor-7.8.8-0.4.1 and it works. -->VERIFIED
Comment 7 errata-xmlrpc 2013-03-06 13:44:27 EST
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

Note You need to log in before you can comment on or make changes to this bug.