| 1 |
This file contains release notes and a change history for the |
| 2 |
lrms python module. |
| 3 |
|
| 4 |
Release 2.2.0 : first release of this package as a separate RPM. Both lcg-info-dynamic-scheduler |
| 5 |
and lcg-info-dynamic-scheduler-pbs depend on this python module, makes sense to have it as a |
| 6 |
separate RPM. Otherwise this is identical to the lrms.py module shipped with the |
| 7 |
lcg-info-dynamic-scheduler-generic package since version 2.1.0. |
| 8 |
|
| 9 |
Below refer to versions of lrms.py that were release with the lcg-info-dynamic-scheduler-generic pacakge. |
| 10 |
This was before the restructuring of the RPMs. Hence the version numbers refer to lcg-info-dynamic-scheduler-generic. |
| 11 |
|
| 12 |
Release 2.1.0 |
| 13 |
|
| 14 |
lrms.py was changed in order to support caching of search results. |
| 15 |
Most of the time spent in lcg-info-dynamic-scheduler was due to |
| 16 |
queries like "find all jobs from group 'lhcb', in state 'waiting', |
| 17 |
for queue 'qlong'. Queries like this are now cached for future use, |
| 18 |
and can also be supplied *before* use, like they now are for |
| 19 |
lcg-info-dynamic-scheduler. That program now generates slices |
| 20 |
of the job list for the various combinations queue/group/state |
| 21 |
that will be needed while running the program. |
| 22 |
|
| 23 |
There were previously two different 'return a list of matching job' |
| 24 |
functions, with different interfaces. These now have a unified |
| 25 |
interface so that result caching can be supported. This does break |
| 26 |
backwards compatibility for lrms.py. |
| 27 |
|
Parent Directory
| 
Revision Log