Deployment team & sites

Tuesday 23 Nov 2010, 11:00 → 12:16 Europe/London

EVO - GridPP Deployment team & sites meeting

Jeremy Coles

- This is the biweekly DTEAM & 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 77907 with code: 4880.

Minutes dteam-2010-11-23.txt

11:00 → 11:20 Experiment problems/issues

Review of weekly issues by experiment/VO - LHCb -- Check on transfer problems http://hepwww.rl.ac.uk/nraja/UKUploadProblems/index.html - CMS - ATLAS -- http://pprc.qmul.ac.uk/~lloyd/gridpp/hammercloud.html - Other - Experiment blacklisted sites - Experiment known events affecting job slot requirements - Site performance issues From sites: Bham: "There are two outstanding problems at Birmingham. The CreamCE feeding our shared cluster (epgr07.ph.bham.ac.uk) is a bit unstable. I'm not sure why this is, but it's under investigation. The second is that ATLAS are busy reinstalling their software on our shared cluster after our NAS failed. I don't think there are any problems with this process, but their software experts have been involved on GGUS ticket: https://gus.fzk.de/ws/ticket_info.php?ticket=64453 And we've moved to glite-APEL 3.2 :-)"

11:20 → 11:35 Meetings & updates

- ROD team status (any points to raise to sites or issues to follow up?) - Tier-1 update - Please take note of the updates from the last GDB. -- The agenda and talks: http://indico.cern.ch/conferenceDisplay.py?confId=83604 -- Pete's notes: http://www.gridpp.ac.uk/wiki/GDB_10th_November_2010. - Feedback on GOCDB4 -- Functionality that is lost or hidden! -- Comments on the interface

11:35 → 11:45 Test infrastructure

1) Do we run dedicated services for the SE/WMS/myProxy rather than use existing and/or production instances of the services. 2) If dedicated services are to be run, do we agree that a single box is the way to go? 3) What cost point should we consider for the hardware?

11:45 → 11:50 WLCG Tier-2 availability, accounting and misc results

- Accounting has stopped for UKI-SOUTHGRID-CAM-HEP and possibly UKI-SCOTGRID-DURHAM. - ATLAS SAM issues recently at CAM-HEP; Liverpool & Manchester? - Steve's jobs have high failure rate at QMUL! A standing reminder: "glite-apel has been in production since June, last week 5/25 UKI sites only had migrated and R-GMA will shut down at the end of the year. 30 days after they last publish sites will fail a critical test as well as not meeting gridpp requirement". also CREAM still awaited at several sites. Any updates? My previous summary: "UK readiness/testing these sites now have CREAM available for production: RAL T1; Glasgow; Manchester; Oxford; Birmingham; Imperial; Liverpool; RALPP; QMUL and Sheffield. The remaining sites vary from having a test instance to still planning: UCL; Lancaster; Brunel; Cambridge; Bristol and Durham."

11:50 → 12:00 Reminders

Operational Security Procedures: https://documents.egi.eu/public/ShowDocument?docid=47. If requesting a new role in the GOCDB, as a precaution please email Jeremy (there is no pending request alert in GOCDB). PMB statement on security (following last dteam+sites meeting comments): "The GridPP PMB encourages sites to make decisions on security related matters in accordance with their own site's security policy and the common wLCG/EGI/GridPP security policy (reference EGI document currently awaiting EGI PMB sign-off), taking into account the advice received from their own site security team, the information provided by the GridPP security team, and in consultation with other sites. The PMB acknowledges that security responses may differ from site-to-site, reflecting different institutional policies, grid architectures, configurations and installed packages. Ultimately, each site must weigh the risk vs benefit of continuing to provide a service. The risk analysis must consider the severity of the threat; the time-frame of the exposure; the risk that lack of response would cause to other sites, services and the infrastructure; and the ability of a site to monitor and respond. GridPP encourages sites to consider each incident objectively and does not wish to influence, in either direction, the outcome of that consideration. That is, GridPP does not encourage sites to take on a higher level of risk than they feel comfortable with in order to preserve service, nor does GridPP encourage sites to shutdown service prematurely to eliminate small risks." - For those who missed the HEPSYSMAN meeting the talks are mostly now uploaded to: http://indico.cern.ch/conferenceDisplay.py?confId=114368.

12:00 → 12:05 AOB

- Deployment planning.