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
There are minutes attached to this event.
Show them.