Choose timezone
Your profile timezone:
FTS3 Steering
- Release candidate is 3.5.x. Patch version will depend on the iterations while running on the pilot.
From Atlas document
- Atlas asked how to figure out the version that is running on a server
- REST publishes it on the root directory. i.e https://fts3.cern.ch:8446/
- "api": {"major": 3, "minor": 4, "patch": 2}
- Devs should find a way of publishing also the core version [FTS-703]
- REST publishes it on the root directory. i.e https://fts3.cern.ch:8446/
- Atlas agreed to move part of the production load to the Pilot service
- Rather than a one-time only, this load can remain indefinitely, providing invaluable feedback for devs
- XrdCp transfers from EOS to Castor, used by anybody?
- Not via FTS, although CMS uses XrdCp directly. Satisfied with the results.
- The gfal2 xrootd plugin relies on the xrood libraries, so it is mature enough
- There are some concerns about the suitability of xrootd outside internal CERN transfers
- Fair-share: Since FTS schedules per link, and then by activity, some higher priority transfers A ->D can be starved by lower priority transfers from other links (X->D) since they are scheduled first, and exhaust the storage limitation of D
- Breaking the strict ordering of FTS when scheduling may be enough, and easier to implement [FTS-704]
- There is a fair amount of small files coming from Atlas. Session reuse will help when switching to GsiFTP only.
- Can FTS decide when to use it?
- As of today, session reuse is for the whole job, or nothing.
- Low hanging fruit: jobs with several small files [FTS-705]
- Very long term: cross check theoretical bandwidth with achieved throughput. Can this provide feedback for FTS?
Configuration
- Needs to be armonized, so VOs know what are other doing, what are the values...
- Need to involve all parties (VOs, devs...)
- Consultancy from devs may be required for setting the values as well
- Maybe better to iterate that keep discussing
- Agreed on creating a JIRA project to keep track of why changes are done
- FTS provides an audit, but not tracking of rationales
- JIRA for the moment, to consider integration (i.e. automatic integration of ticket creation)
- [FTS-706]
Other
- Stalled connections: small improvements at CERN, but not yet 100% solved
- To notify sites configuration changes required once CERN dissappear from the alerts
- Disabling Gridsite passcode files and max requests per client seem to help, but only help
- Deletion:
- ATLAS, CMS and LHCb do not use, and do not plan to use deletions
- To be removed [FTS-707]
- SOAP
- Only CMS pending migration, but going as planned
- ~2 months the REST implementation will go to production (this is, ~beginning of November)
- Calendar is maintained: [FTS-600], [FTS-601]
- Monitoring being put in place to trace users still using SOAP
- SOAP can be shutdown progressively before the rollout of 3.6 to detect outliers
- Downtime may be required for 3.6 and database optimizations
- No objections by anyone
- Pilot can be used as pivot
- No need to drain, but yes to stop submitting
- Poller may keep running, so either read-only access or 503 statuses need to be returned
- To discuss the dates. January doesn't seem to fit.
There are minutes attached to this event.
Show them.
