Operations team & Sites

Tuesday 13 Nov 2012, 11:00 → 12:16 Europe/London

EVO - GridPP Operations team meeting

- This is the biweekly ops & sites meeting - The intention is to run the meeting in EVO: http://evo.caltech.edu/evoGate/. Join the meeting in the GridPP Community area. - The phone bridge number is +44 (0)161 306 6802 (CERN number +41 22 76 71400). The phone bridge ID is 14 0782 with code: 4880. Apologies:

Minutes Ops13Nov2012minutes.txt

11:00 → 11:20 Experiment problems/issues

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

11:20 → 11:40 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

11:40 → 12:00 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.

Main-paper-v2 Software_Lifecycle_Management_for_WLCG_beyond_EMI-V-0.2.pdf

Paper-condensed SLM-condensed.pdf

Summary WLCG-MB-SoftwareLifecycleIntro-2.pdf

11:55 → 12:00 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.

Slides 2012-perfsonar-mesh.pdf

12:00 → 12:01 AOB