FTS 3.6 upgrade [Checklist]

• Pruning transfers finished more than 4 days is acceptable
• ATLAS, CMS and LHCb give green light for the update
• Agreed for Tuesday 4th, 10.00 AM
• Two hours downtime to be expected
• ATLAS will drain and switch to the pilot
• CMS will not account failures for the availability/reliability of sites during this period

Staging

• FTS teams should add a view to easily identify files that are causing errors, so sites can debug
• The monitoring view will include more information once production instances are upgrades
• Not all T1 tapes are the same (different sites may have different limitations)
  • Does FTS needs to be able to be configured per storage?
• David Mason will prepare a list of questions for T1 sites about tape params and what FTS could do
  • To be sent to fts3-steering@cern.ch
  • Giuseppe Lo Presti will help
• Once production is upgraded, LHCb, ATLAS and CMS will try to see how GridKa tapes performs/handle fair shares

AOB

• ATLAS asks for more frequent releases if possible
  • 3.5 was fully rolled out end of november, with Christmas in the middle it hasn't been that long
  • Bugfixes are normally rolled out quickier
  • FTS will consider faster iterations of releases with new features
• ATLAS find hard to dig through errors, so they can better understand the reasons, and ask sites for explanations
  • FTS already tags errors as SOURCE, DESTINATION and TRANSFER
  • FTS 3.6 will also tag errors as STAGING
  • To facilitate categorization, and as gfal2 already tries doing this, FTS will publish the error codes as well (FTS-926)
• CMS considering using FTS for staging as well
  • FTS teams should send to Natalia some documentation on this