Category | Item | Responsible | Priority (1-5) | Completion (%) |
---|---|---|---|---|
Bug fixes | check for any critical bugs outstanding | Oliver | 5 | 0 |
OSG | Components needed for OSG interoperation | Laurence | 5 | 0 |
VO-BOX | Job submission capability via condor | x | 1 | 0 |
VO-BOX | The VO-BOX is published in the info system. We need a mechanism that allows the VOs on the box to add their own key value pairs. | Laurence | 3 | 0 |
VO-BOX | List of trusted domains / networks for iptables configuration | Maarten | 4 | 0 |
Info system | Cleanup of the info providers to make full use of the new glue schema | Laurence | 0 | 0 |
Info system | Update of info providers to publish versions for each service | Laurence | 3 | 0 |
Info system | Add the GlueSchemaLocation for exp installed software | Laurence | 0 | 0 |
Info system | Add a key value pair to the info provider for services that declairs the service as being part of production. This is already published for some services, but YAIM is not configuring this. | Laurence | 0 | 0 |
Info system | VOMS server info provider | Laurence | 0 | 0 |
Info system | Jeff Templon's ETT (the NIKHEF ETT RPMs) | Jeff | 5 | 0 |
LFC/DPM | ReadOnly LFC - replication | Jean-Philippe | 4 | 0 |
LFC/DPM | VOMS enabled DPM and LFC | Jean-Philippe | 2 | 0 |
LFC/DPM | srm-copy | Jean-Philippe | 0 | 0 |
LFC/DPM | using the internal catalogue as a local file catalogue | Jean-Philippe | 0 | 0 |
Backup | Back up mechanism for the mission critical DBs on the T2 and smaller centers. Mainly DPM, local LFCs, dCache internal DBs. These are critical when lost. Has to be simple, with an option to sent the backup up the chain to the corresponding T1 center (data management tools??) Probably supplied in the first instance as a HOWTO | x | 2 | 0 |
Separation of state and processing | Services like the CE, RB, MyProxy ... maintain extensive state information that needs to be available to restart the service in case the node crashes. We have done this for the RB, now the other services should follow. | Andrey | 0 | 0 |
Job monitoring tools (job mon and stdOut/Err mon) | Update, reflecting the input that we receive by the users (some feedback has been already given). | Laurence | 0 | 0 |
Job monitoring tools (job mon and stdOut/Err mon) | Ensure these are off by default. | Laurence | 0 | 0 |
RB | Currently there is no explicit link between the jobID and the VO in the Logging and bookkeeping DB. This makes queries like: Show me the state of all jobs of my VO a bit complex. Which are the queries that the experiments would like to see. | David | 0 | 0 |
Security | make the fork job manager be properly authorized as previously discussed | Maarten | 0 | 0 |
Security | determine what can and can not be done about pool account recycling, the threats it poses and what we can do about it, if anything | x | 0 | 0 |
Security | signed rpm distribution might also be nice. | Louis | 0 | 0 |
BDII | The top level BDIIs should be published as services by the site BDII | Laurence | 0 | 0 |
BDII | we need an info provider that can add a few values that reflect the load on the node | Laurence | 0 | 0 |
VO management via YAIM | Problem: Currently we decide at CERN which VOs are already there by default (and which are not). Possible solution: A web based tool that displays all VOs with a short description and a comment by the ROC managers of the sites region. The site then selects the VOs and assigns shares (in case the site uses a fair share scheduler). The tool then creates the VO dependent information for YAIM. A clear distinction between pilot VOs and others has to be made. | Oliver | 0 | 0 |
VO management via YAIM | If the web tool is not ready, make sure info for as many VOs as possible is shipped with yaim, ensure GEANT4 and UNOSAT are there. | Oliver | 0 | 0 |
VO management via YAIM | Default VOs are to be 4 LHC experiments + biomed + dteam + MIS (for monitoring) | Oliver | 0 | 0 |
Monitoring | Remove gridftp monitor from the CE. | Laurence | 0 | 0 |
RB Sandbox | Add a smart mechanism that limits the output sandbox size on the RB. We have a mechanism for the input sandbox already in place. The recently observed jobs with stderr files > 2GB can bring down any RB. The mechanism should work like this: The limit has to be configurable Sort all the files in reverse order by size Transfer all the files that fit into the limit For the remaining files transfer the first and last 100K and a note on the original size of the files |
Maarten | 0 | 0 |
VDT/Globus | Upgrade to more recent version of VDT and Globus. This should be synchronized with OSG and gLite |
Maarten | 0 | 0 |
R-GMA | Inclusion of the latest R-GMA ( gLite 1.5 ) | x | 0 | 0 |