DIRACGrid/DIRAC — Issue #401: Bad RSS utility implementation
Author: atsareg
Created: 2012-01-04 15:05:46+00:00
State: open
Labels: Bug, RSS

When passing to v6r1 the following exception has occurred in the optimizer code:

2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer INFO: == Processing job 14166 ==
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer INFO: Next optimizer for job 14166 is JobScheduling
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer INFO: Loading optimizer JobScheduling
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: LOADERROR
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: == EXCEPTION ==
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: :Path /Resources/FileCatalogs/LcgFileCatalogCombined does not exist or it's not a section
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: File "/vo/dirac/pro/DIRAC/WorkloadManagementSystem/Agent/MightyOptimizer.py", line 159, in __loadOptimizer
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: locals(), agentName )
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT:
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: File "/vo/dirac/pro/DIRAC/WorkloadManagementSystem/Agent/JobSchedulingAgent.py", line 25, in
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: from DIRAC.ResourceStatusSystem.Utilities.CS import getSiteTiers
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT:
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: File "/vo/dirac/pro/DIRAC/ResourceStatusSystem/__init__.py", line 10, in
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: from DIRAC.ResourceStatusSystem.Utilities import CS
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT:
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: File "/vo/dirac/pro/DIRAC/ResourceStatusSystem/Utilities/CS.py", line 128, in
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: def getLFCNode( sites = getLFCSites(),
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT:
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: File "/vo/dirac/pro/DIRAC/ResourceStatusSystem/Utilities/CS.py", line 126, in getLFCSites
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: % g_BaseResourcesSection, True))
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT:
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: File "/vo/dirac/pro/DIRAC/ResourceStatusSystem/Utilities/Utils.py", line 146, in unpack
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: raise RPCError, dirac_value['Message']
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer EXCEPT: ===============
2012-01-04 13:57:38 UTC WorkloadManagement/MightyOptimizer ERROR: Optimizer 14166 Job JobScheduling: Can't load optimizer JobScheduling: Path /Resources/FileCatalogs/LcgFileCatalogCombined does not exist or it's not a section

This raises quite a number of questions.

First, RSS/Utilities/Utils/unpack function should be irradicated and replaced by the DIRAC conventional method of dealing with errors in function calls. This function transforms S_ERROR into an exception. The DIRAC convention is NOT to use exceptions but:
- use S_ERROR
- ALWAYS check the returned result in this form

The example above shows nicely that exceptions are not caught properly resulting in uncontrolled failures.

Second, in CS.py, line 128:
def getLFCNode( sites = getLFCSites(), readable = ('ReadOnly', 'ReadWrite')):
...
giving default values as a function call is a very bad practice if even python allows that. This function is called when the module is just imported which is certainly not the intention. So, the function should be called inside the body and not in the definition.

Please, correct the above as soon as possible. This causes problems with non-LHCb DIRAC installations.