Week of 160801

WLCG Operations Call details

• At CERN the meeting room is 513 R-068.

• For remote participation we use the Vidyo system. Instructions can be found here.

General Information

• The purpose of the meeting is:
  • to report significant operational issues (i.e. issues which can or did degrade experiment or site operations) which are ongoing or were resolved after the previous meeting;
  • to announce or schedule interventions at Tier-1 sites;
  • to inform about recent or upcoming changes in the experiment activities or systems having a visible impact on sites;
  • to provide important news about the middleware;
  • to communicate any other information considered interesting for WLCG operations.
• The meeting should run from 15:00 until 15:20, exceptionally to 15:30.
• The SCOD rota for the next few weeks is at ScodRota
• General information about the WLCG Service can be accessed from the Operations Web
• Whenever a particular topic needs to be discussed at the daily meeting requiring information from site or experiments, it is highly recommended to announce it by email to wlcg-operations@cernSPAMNOTNOSPAMPLEASE.ch to make sure that the relevant parties have the time to collect the required information or invite the right people at the meeting.

Tier-1 downtimes

Experiments may experience problems if two or more of their Tier-1 sites are inaccessible at the same time. Therefore Tier-1 sites should do their best to avoid scheduling a downtime classified as "outage" in a time slot overlapping with an "outage" downtime already declared by another Tier-1 site supporting the same VO(s). The following procedure is recommended:

1. A Tier-1 should check the downtimes calendar to see if another Tier-1 has already an "outage" downtime in the desired time slot.
2. If there is a conflict, another time slot should be chosen.
3. In case stronger constraints cannot allow to choose another time slot, the Tier-1 will point out the existence of the conflict to the SCOD mailing list and at the next WLCG operations call, to discuss it with the representatives of the experiments involved and the other Tier-1.

As an additional precaution, the SCOD will check the downtimes calendar for Tier-1 "outage" downtime conflicts at least once during his/her shift, for the current and the following two weeks; in case a conflict is found, it will be discussed at the next operations call, or offline if at least one relevant experiment or site contact is absent.

Links to Tier-1 downtimes

ALICE	ATLAS	CMS	LHCB
	BNL	FNAL

Monday

Attendance:

• local: Andrea M (MW Officer), Andrea V (LHCb), Belinda (storage), Emil (databases), Fa-Hui (ASGC), Julia (WLCG), Maarten (SCOD + ALICE), Maria D (GGUS)
• remote: David B (IN2P3), David M (FNAL), Kyle (OSG), Peter (ATLAS), Sang-Un (KISTI), Stefano (CMS), Tiju (RAL), Ulf (NDGF), Vincenzo (EGI)

Experiments round table:

• ATLAS reports (raw view) -
  • Activities:
    • Low in MC simulation but 60M events added mid-week. 800M Sherpa request not ready yet.
    • Some grid production at T0, looking to use all 10k slots
  • Problems:
    • Kibana/ES unreliable again for important service monitoring GGUS:123021
    • RRC-KI DATADISK full but SRM query shows 450TB free so investigating inconsistency GGUS:123198
    • Castor garbage collection stuck causing pool to get full ALARM:123148
      • see CERN storage services entry below
    • CERN/BNL test 3GB/s but didn't saturate link
    • Triumf/cern link saturated 10Gbit/s
    • Overlay tasks stress Frontier when run at many T2 sites. Better squid HITS when restricting to BNL. Further work needed.
    • Heavy-Ion tasks using high memory >64G, queried with HI group to review situation as not sustainable

• CMS reports (raw view) -
  • Load from user analysis down as expected as ICHEP is starting, Production still high.
  • Production slowed Friday/Saturday due to problem in dashboard: CMS submission system uses Dashboard Site Status Board to read target valued for CPU-bound and IO-bound jobs at each site, but those values disappeared from the metric page. This is basically semi-static grid topology information, eventually should move out of a monitoring tool.
    • Alarm ticket opened Saturday GGUS:123190 IT operator called Pablo Saiz who solved very quickly, thanks. Issue tracked to an old rpm deployed by mistake on dashboard servers on Thursday.
  • Kibana monitoring pages show very often data gaps and delayed updates. Not clear where problem is. One ticket opened this morning INC:1092589 Mostly a worry than a problem at the moment.
    • Maarten: in the Ops Coordination meetings of Sep we can discuss to what extent monitoring systems are to be considered critical
    • Julia: the WLCG Workshop in San Francisco also has a slot on monitoring where experiments can provide input

• ALICE -
  • CERN: as of July 28 00:00 CEST jobs are also being submitted to the T-Systems external cloud resources
    • up to ~2600 cores, the total capacity that was available so far
    • job success rates have been good
    • job types include MC, reco and user analysis
      • analysis trains were excluded to reduce the load on the 10 Gbps link to CERN

• LHCb reports (raw view) -
  • Activity
    • Monte Carlo simulation, data reconstruction/stripping and user jobs on the Grid
  • Site Issues
    • T0: Most pilots aborted on ce406 during the weekend (GGUS:123208). Older tickets still open about VOMS (GGUS:122471) and pilot issues due to proxy (GGUS:123026).
    • T1: Issue with pilot and proxy at CNAF still open (GGUS:123027), similar to the one still open at CERN.

Sites / Services round table:

• ASGC: ntr
• BNL:
• CNAF:
• EGI: ntr
• FNAL:
  • some trouble with our GUMS service is preventing new jobs from starting; being investigated
• GridPP:
• IN2P3: ntr
• JINR:
• KISTI: ntr
• KIT:
• NDGF:
  • a broken 10 Gb switch in Bergen prevents access to some of our ALICE data; expected to be fixed tomorrow or soon after
• NL-T1:
• NRC-KI:
• OSG: ntr
• PIC:
• RAL:
  • On Saturday evening, there were some SAM test failures for ALICE due to a misbehaving disk server. Fixed by restarting services on the server.
• TRIUMF:

• CERN computing services:
• CERN storage services:
  • CASTORATLAS Alarm ticket: traced to an Oracle bug that made many DB connections stuck, including the ones dealing with the Garbage Collector. Problem fixed this morning with an Oracle patch (OTG:0032004).
• CERN databases:
  • the CMS online DB HW issues have been resolved
• GGUS:
  • (By Maria D.) Everything was successful with the release last Wed. 27 July. Release notes: https://ggus.eu/?mode=release_notes Please observe the https://ggus.eu/?mode=didyouknow#2016-07-27 about notifying all the T1s in one go.
• Monitoring:
  • Final reports for the June 2016 availability sent around
    • there still is an issue affecting ATLAS that will be corrected (GGUS:123126)
• MW Officer:
  • Some of Grid MW packages got retired from Fedora because they are missing Systemd support (https://fedorahosted.org/fesco/ticket/1605): BDII, VOMS, dpm-dsi and globus-gridftp-server. Need to understand if this will impact packages in EPEL6 or it's a blocker only for future package releases.
• Networks:
• Security:

AOB: