FTS3 - Steering meeting

Wednesday 2 Dec 2015, 15:30 → 17:30 Europe/Zurich

31/S-028 (CERN)

The topics for this meeting will be mainly related to operations: - SOAP deprecation plans - Release rollout - IPv6 load balancing - Database schema changes - Potential new services, problematic? - Feedback from FTS3 system administrators

FTS 3.4.0 Release Notes

SOAP Deprecation plan

• Exposed deprecation plans for SOAP. No objections.
• Atlas to decide if they want to upgrade 3.3.3 already, or rather wait for 3.4 after the Christmas break
  • FTS 3.3.3 contains fixed for duplication of transfers, but so does 3.4
  • http://helicon.cern.ch:8080/cep/pattern
• Atlas asks FTS3 development to notify in advance when high load from the stress tests is to be expected towards production endpoints
• Notified change of group of FTS dev and FTS ops at CERN as a result of the IT department reorganization
• IPv6 and load balancing
  • HAProxy, mentioned by Andrew, sounds like a good solution
  • In principle, Steve doesn't expect it to be complicated to implement at CERN
• Database schema changes
  • Acceptable if brings real benefits
  • Needs coordination with experiments in order to drain the queues
• New services to support FTS3
  • Acceptable, but having simple identical machines is a plus
• Backup tables
  • Three months enough for Atlas
• User-provided job ids
  • Proposed solution of using uuid 3 or 5 positively seen by Atlas, details to be discussed
• Knowledge base
  • To be used as a reference by sites
  • http://fts3-docs.web.cern.ch/fts3-docs/docs/kb.html

1 SOAP Deprecation Plans

FTS3_Steering_Dec_SOAP.pdf

FTS3_Steering_Dec_SOAP.pptx

2 Release Rollout & Ops Discussion Points

FTS3_Steering_Dec_Other.pdf

FTS3_Steering_Dec_Other.pptx

Raised by Andrew

1. When will sites be requested to upgrade to 3.3.3? I had been expecting this to be fairly important, in particular for ATLAS, as it fixes the duplicate transfers problem AFAIK.

2. Do we really need to keep transfers in the backup tables 'indefinitely'? Does anyone actually use this? It results in the size of the database being very, very big, and constantly getting bigger and bigger...

3. Are any sites using a load-balancer instead of round-robin DNS in front of the FTS3 servers? I intend to move to using a pair of machines using HAProxy + Keepalived. HAProxy will be running health-checks on each FTS3 server so that dead or broken nodes will no longer be accessible by clients - that way we will be able to (finally) do transparent upgrades (!), or have an FTS3 server or two die overnight without anyone having to be woken up by a pager. It's also a first step in being able to eventually move to a more dynamic infrastructure.

3 AOB