Week of 160328

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: Easter Monday holiday

• The meeting will be held on Tuesday instead.

Tuesday

Attendance:

• local: MariaD (SCOD), Maarten (ALICE), Jerôme (CERN Computing), Alessandro Fiorot & Xavi (CERN Storage), Kate (CERN DB).
• remote: Michael Ernst (BNL), Daniele Bonacorsi (CMS), David Cameron (ATLAS), Dmytro Karpenko (NDGF), Onno Zweers (NL_T1), Tommaso Boccali (CMS), Kyle Gross (OSG), Di Qing (Triumf), Rolf Rumler (IN2P3), John Kelly (RAL).

Experiments round table:

• ATLAS reports (raw view) -
  • MC15c (digi+reco reconstruction) running smoothly and taking up most of the grid slots
  • INFN-T1 downtime: 5 day downtime was scheduled at 2 days' notice was very disruptive to ATLAS operations. No mention at previous WLCG meetings and no personal notifications from the site. This is not acceptable from a T1.
  • A VOMS-related issue seems to be affecting both panda and FTS since the evening of the 28th. Services fail to extract FQANs from the proxy

Nobody connected from CNAF to comment on their long downtime. Maarten will check whether the issue related to requested proxies lasting longer than the voms server's host certificate are related to the voms or the arc client and will open a ticket with all the information verified: GGUS:120463 for the VOMS devs.

• CMS reports (raw view) -
  • mostly smooth sailing
  • getting prepared for start of massive 2016 MC production. Should be within days. We will try to push as much as possible via Multi core pilots.
  • Last week we had again a glitch in SAM, with CONDOR tests (GGUS:120446) - seems linked to an openstack problem on the SAM infrastructure.
  • CMS twikies inaccessible on March 28. GGUS ALARM (GGUS:120448) since it was affecting our operators. Promptly addressed.
  • Problem with FTS3/CERN: GGUS:120454 "Starting from yesterday some of authentications are timing out"

Daniele expressed gratitude to the twiki expert, Pete Jones, for solving the issue in a few minutes, despite the Easter Monday holiday. Maarten and Maria confirmed twiki unavailability can justify an ALARM ticket according to the Critical Services' list and the MoU value chosen was correct. Maria will explain offline alternative ways to publish instructions to shifters - see Use Case 2 on ...LHC experiment experts, shifters, users... HERE.

• ALICE -
  • mostly high activity
    • new record 99376 running jobs this morning

Xavi said the intervention for ALICE took place and, happily, it was totally transparent.

• LHCb reports (raw view) -

Nobody connected and no report.

Sites / Services round table:

• ASGC: not connected
• BNL: smooth operation
• CNAF: not connected
• FNAL: not connected
• GridPP: not connected
• IN2P3: NTR
• JINR: not connected
• KISTI: not connected
• KIT: Downtime (GOCDB:20261) today until tomorrow for LHCb in order to install new storage resources. Unfortunately, the lead time to this maintenance intervention was very short for us as well as LHCb.
• NDGF: Next Monday the data services will experience a few minutes' outage due to java update on dcache headnodes. Downtime created GOCDB:20347.
• NL-T1:
  • Reminder: downtime Sara 5&6 of April.
  • Reminder: in October, Sara will move to a new data center. Disk data with a single copy will be at risk. Adjust your data strategy if needed.
• NRC-KI: not connected
• OSG: NTR
• PIC: not connected
• RAL: There were network problems at RAL from approx 19:00 24/03/2016 until approx 13:00 25/03/2016. One link of a four link channel failed. There was some disruption, failed SAM tests and GGUS tickets.
• TRIUMF: Last week there were two network incidents at TRIUMF, one was on March 21 from 14:21 to 17:40 (local time) and another one March 22 from 17:35 to 18:53 (local time), it was caused by a bug in SSH scanner filter on site firewall, all research network traffic were rejected by the firewall during those two periods. Since institute DNS servers are on research network, although LHCOPN and LHCONE network still worked, all traffic from/to TRIUMF T1 were affected.

• CERN computing services: VOMS server certificates were about to expire, preventing proxies past the expiry date from being generated. Fixing...
• CERN storage services: Deployed this morning the new server for EOSALICE MGM (512GB of memory). These new servers double the memory and will solve the instabilities observed during the last month related to sporadic memory exhaustion as a result of the high number of files on 256GB RAM machines.
• CERN databases: Machines running 2 out of 4 nodes of CMSONR database will be migrated to their final destination in the RAC on Thursday morning. The database will be accessible but at risk during the intervention.
• GGUS: Check here the test ALARMs. All WLCG sites responded well. Always check the Did You Know? for good functionality tips.
• MW Officer:

AOB: (MariaD) Tier1s were invited at the MWR and the the Ops Coord meetings on 16 & 17/3 to tell the e-group wlcg-ops-coord-wg-middleware at cern.ch whether they agree to install the pakiti client on their production service nodes, so that the versions of MW run at the site be known to authorised DNs site managers taken from GOCDB and expert operations' supporters. Site replies on their intention to expand the use of pakiti client can be found here. I'll put 2 reminders to sites in the twikis of the April 7th and 28th Ops Coord meetings, as part of the MW Readiness WG report. All the input received is being concatenated and attached to the next MW Readiness WG meeting agenda of May 18th. Then we'll conclude on the issues.