• It was necessary to add WriteToken for TRIUMF tape even for SRM+HTTP(?)
• TAPE Testbed
  • Functional Tests TAPE (transfer matrix)
    • now using fts3-devel with gfal2 2.20 (integrated SciToken support)
    • configuration updated to prefer SRM+HTTP on Monday evening
    • SRM URL parameters not passed to TURL (e.g. copy_mode=pull)
      • rely on global FTS configuration
    • removed RAL & SLAC from matrix (unreliable)
  • Transfers from dCache tape source (BNL, TRIUMF) have high failure rate
    • StoRM tape source works fine
    • any tape destination works fine
    • dCache transfer fails after 5s with StoRM destination with error "failure: SocketTimeoutException while fetching URL: Read timed out" or after 120s for DPM destination (0 bytes transferred)
      • StoRM has 5s timeout for not receiving any data
      • DPM by default use 120s timeout to detect low transfer rate
      • at least in case of BNL this can be side effect of their internal dCache topology with external doors - this will be discussed with developers in a mail thread that we already started with BNL
        • NDGF on the other side works fine
    • trying to involve more dCache tape sites (e.g. NDGF with dCache 7.x, FNAL)
  • 
• Rucio implemented support for "new" protocol SRM+HTTPS (rucio#4506)
  • keeping SRM+GridFTP in addition to SRM+HTTP is too complicated and not really necessary
    • tape SRM endpoints can support just one protocol (either HTTP or GridFTP)
      • no direct transfers between SRM+GridFTP <-> SRM+HTTP tape, but there was 0 direct TAPE to TAPE production ATLAS transfers during last 30 days
      • fine assuming most of disk sites still support both GridFTP and HTTP
    • for different protocols => Rucio automatically multihop