Deployment team & sites

Name: Deployment team & sites
Start: 2010-10-26T11:00:00+01:00
End: 2010-10-26T12:16:00+01:00
Location: EVO - GridPP Deployment team & sites meeting

Tuesday 26 Oct 2010, 11:00 → 12:16 Europe/London

EVO - GridPP Deployment team & sites meeting

Jeremy Coles

Description

- 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 64688 with code: 4880.

- 11:00 → 11:20
  
  Experiment problems/issues 20m
  
  Review of weekly issues by experiment/VO - LHCb -- Check on transfer problems http://hepwww.rl.ac.uk/nraja/UKUploadProblems/index.html - Only Brunel now seeing problems? - CMS - ATLAS - Other - Experiment blacklisted sites - Experiment known events affecting job slot requirements - Site performance issues
  
  Minutes
- 11:20 → 11:40
  
  Meetings & updates 20m
  
  - ROD team status (any points to raise to sites or issues to follow up?) - SAM style email notifications of problems are now available from the GridPP Nagios instance. There is no web interface and messages can only be sent to email addresses registered in the GOCDB. There is also a new RSS feed from the Operations Portal for any site to receive alerts of critical alarms at a specified site (e.g. http://operations-portal.in2p3.fr/rss/nagiosNotifications/site/RAL-LCG2). - Tier-1 update Operational security - the recent vulnerability (patch) and response OPN troubleshooting - At the last LHCOPN meeting, the LHCOPN community was mandated to design a solution to improve network connectivity for the LHC Tier2s. Anyone interested in actively participating in the discussions can now join the discussion list via https://e-groups.cern.ch/e-groups/Egroup.do?egroupId=218645. - Comments/observations from CHEP -- http://indico2.twgrid.org/conferenceTimeTable.py?confId=3 - Escalated tickets https://gus.fzk.de/download/escalationreports/roc/html/20101025_EscalationReport_ROCs.html 4 tickets on hold. 56316 - NGS-RAL not in BDII 58733 - RAL-PP biomed. dcache issue. 60712 - csTCDie - ATLAS GOCDB entry. Can be closed? 61228 - ALICE RAL T1.
- 11:40 → 11:45
  
  Deployment priorities & timelines (reminders) 5m
  
  - https://twiki.cern.ch/twiki/bin/view/EGEE/LCGprioritiesgLite#07_10_2010 - CREAM. Testing continues by the experiments with positive results. We should anticipate a switch from the shortly unsupported LCG-CE. - APEL - RGMA will be switched off at the end of the year. So moving to the new gLite-MON is becoming urgent. - ARGUS - The security policy suspension will be reviewed again in December/January.
- 11:45 → 12:00
  
  gstat - installed capacities & pledges 15m
  
  - Observations & comments (following up from the last discussion) 1) Many of our sites misreport in the "Total" column for Grid Jobs on pages like http://gstat-prod.cern.ch/gstat/summary/GRID/GRIDPP/. Often the figure is out by a factor related to the number of CEs at the site. We know that there are methods for publishing sub-clusters that help in other areas. Do you have evidence that following the sub-cluster recommendations leads to correct figures in gstat? LF: I don't have any evidence but have not had any complaints. If you find that following the guidelines ( outline in the Install Capacity Document), does not work for you, please let me know. This presumably then also affects the Running and Waiting figures (the Total is defined as the direct sum of these two?) 2) gstat reports different numbers in different views. Here is an example: Here Manchester has 223TB - http://gstat-prod.cern.ch/gstat/site/UKI-NORTHGRID-MAN-HEP/treeview/se_online/ and here 207.884TB (same as in ldap and from the fs command) http://gstat-prod.cern.ch/gstat/summary/Country/UK/ How does gstat get the 223TB? LF: One view looks at the totals as published in the SE entry and another adds up the SAs. This could cause inconsitencies if the information providers are not reporting correctly. If you believe this is a case please open a GGUS ticket. We have noticed that DPM tools are inconsistent in the way that they retrieve information and whether they use 1024 or 1000 as the blocksize. Oddly DPM also defaults to 1024 rather than SI, but publishes in SI and we will raise this via GGUS with the DPM developers. 3) Will different views report in the same units soon? gstat-prod uses SI2000 while gstat-wlcg uses HEPSPEC06. LF: gstat-prod is for EGI, gstat-wlcg is for WLCG. This is a policy issue. - On the pledges... gstat overview: http://gstat-wlcg.cern.ch/apps/capacities/comparision/ Detailed by site: http://bourricot.cern.ch/dq2/accounting/federation_reports/UKSITES/ Note that in going between the GridPP allocations and the WLCG ones the formula used is "Allocations from above multiplied by the non-UK Tier-2 fractions [ATLAS 80%, CMS 75%]" But at the moment this does not produce the figures put forward to WLCG ....
  
  Pledges-made
- 12:00 → 12:02
  
  AOB 2m
  
  - Next HEPSYSMAN meeting Monday 22nd November in Birmingham. - BDII nomenclature. Discussed last Tuesday. Sites refer to RAL in two main ways: RAL-LCG2 UKI-LT2-Brunel RAL-LCG2 UKI-NORTHGRID-LANCS-HEP RAL-LCG2 UKI-NORTHGRID-LIV-HEP RAL-LCG2 UKI-NORTHGRID-MAN-HEP RAL-LCG2 UKI-NORTHGRID-SHEF-HEP RAL-LCG2 UKI-SCOTGRID-DURHAM RAL-LCG2 UKI-SCOTGRID-ECDF RAL-LCG2 UKI-SOUTHGRID-BHAM-HEP RAL-LCG2 UKI-SOUTHGRID-BRIS-HEP RAL-LCG2 UKI-SOUTHGRID-CAM-HEP RAL-LCG2 UKI-SOUTHGRID-OX-HEP UK-T1-RAL UKI-LT2-IC-HEP UK-T1-RAL UKI-LT2-QMUL UK-T1-RAL UKI-LT2-RHUL UK-T1-RAL UKI-LT2-UCL-HEP UK-T1-RAL UKI-SCOTGRID-GLASGOW UK-T1-RAL UKI-SOUTHGRID-RALPP Discussion concluded that all sites should adopt "RAL-LCG2" which is the official site name.