Experiment problems/issues Review of weekly issues by experiment/VO - LHCb - CMS - ATLAS - Other

Meetings & updates With reference to: http://www.gridpp.ac.uk/wiki/Operations_Bulletin_Latest - Tier-1 status - Accounting - Documentation - Interoperation - Monitoring - On-duty - Rollout - Security - Services - Tickets - Tools - VOs - SIte updates

Software lifecycle management for WLCG beyond EMI - See also additional papers here: http://indico.cern.ch/materialDisplay.py?contribId=12&sessionId=1&materialId=paper&confId=155073. Topic important as the purpose is to provide a starting point for discussions leading to an agreed strategy that can be refined and implemented by a technical working group. - Main focus is how to handle each of the areas that EMI covers: 1. Coordination between Product Teams (PT) 2. Agreement on standards 3. Agreement on roadmaps 4. Concrete planning of major releases and duration of support 5. Link to related projects ( globus etc. ) 6. A central point to gather and discuss requirements 7. Tracking tools 8. Support 9. Middleware configuration 10. Middleware documentation 11. Middleware maintenance and development 12. Build, integration and testing services for SL and Debian (ETICS etc.) 13. Managed repositories 14. Alternative packaging (tarball releases) Paper mentions ScienceSoft (http://sciencesoft.web.cern.ch/). "an initiative to assist scientific communities in finding the software they need, to promote the development and use of open source software for scientific research and provide a one-stop-shop to match user needs and software products and services." Contains many familiar people from EMI/EGI. In early stages. Significant issue is the integration repository for things that can not go into EPEL. The proposed hierarchy of repositories: 1. UMD/WLCG: non EPEL material and specific versions 2. EPEL-stable Additional repositories: 1. EPEL-test: for middleware in staged rollout, managed pilots and verification 2. PT-private: product teams use private repositories for tests and local pilots 3. UMD/WLCG-history: archive of all middleware and dependencies WLCG middleware development and support will depend largely on independent, distributed funding and on voluntary contributions. As a result strict, reliable roadmaps for the implementation of requirements can’t be expected.

Perfsonar - Mesh tests (see slide) - Request to define endpoints in GOCDB. in the scope of the WLCG operations task force for perfSONAR deployment, we agreed that perfSONAR should be published in GOCDB and OIM like any other relevant WLCG service (SRM, CREAM, etc ..). Therefore we created in GOCDB two new service types: net.perfSONAR.Bandwidth net.perfSONAR.Latency The corresponding services in OIM will be created soon as well. We would like to ask GOCDB sites which have deployed instances of perfSONAR, to declare them in GOCDB, under the proper service type. If you are deploying both the Bandwidth and Latency tests on a single machine, please publish the machine both under the Latency and Bandwidth service types.

AOB