Order of priority for repack operations:
1. Finish repacking `atlas_grid`, 31 tapes
2. NA62 create dual copy `na62dual`
3. Repack of public_user to separate `na62` and `*_grid` fileclasses and clean up `/user`
As we have to repack `public_user` in any case, we will try to clean up the `/user` part of the namespace beforehand as much as possible.
See [#878](https://gitlab.cern.ch/cta/CTA/-/issues/878): Clean up CASTOR /user namespace prior to CTA migration
* Set up a DB instance on CASTOR for use in migration tests
* Set up a second EOSCTA PPS instance that can be used for read-only migration and recall tests
* This instance will be used for ALICE migration test, NA62 migration test and NA62 recall tests
See [#35](https://gitlab.cern.ch/cta/operations/-/issues/35) NA62 tests on EOSPUBLIC PPS and [#54](https://gitlab.cern.ch/cta/operations/-/issues/54) Use of FTS archive monitoring experimental feature
* CMS 654 TB test complete (28/08/2020). This was a simple test of throughput from EOS CMS→EOSCTA CMS. No multi-hop or m-bit check. Waiting for Katy to return from holiday to get feedback.
* Multi-hop test next week (w/c 07/09/2020).
* m-bit test to be scheduled.
* This afternoon (03/09/2020) Mihai will present his plans for deploying new version of FTS with m-bit check this afternoon.
* Tentatively, we will migrate CMS after LHCb (**February 2021**). However this can change according to the schedule for Phedex to Rucio migration. Potentially we can migrate CMS before the end of the year if they are ready.
See also [#59](https://gitlab.cern.ch/cta/operations/-/issues/59): Handle failed multi-hop transfers where physical and logical filenames are the same
* (w/c 14/09/2020): Julien will start work on Dirac+CTA integration with Christophe Haen as soon as he gets back from holiday
* Our preferred solution is to use multi-hop DAQ → EOS LHCb → EOSCTA LHCb and to stage out to T1s from EOS LHCb.
* Christophe said (02/07/2020) "I believe we will do without multi-hop in FTS, as per our last discussion." but later said (24/08/2020) "The implementation for the pit export still needs to be refined, but this will anyway go first to EOSLHCb, so no direct impact on CTA once we are sure that EOSLHCb and CTA can talk to each other." This workflow needs to be clarified.
* TPC to T1s: Transfers to Gridka and the other dCache sites will be possible using XRootD TPC with delegation of credentials. Chris said, "...then nothing will prevent us anymore from using xroot as third party, providing it's deployed everywhere (and I really mean everywhere)". However, it will not be deployed everywhere. CNAF use StoRM and will not support this, they will support HTTP TPC. Christ said (25/08/2020), "For CNAF, since we have nothing special with respect to the other VOs there, I rely on the TPC task force to make it work there." Can LHCb handle some transfers with XRoot and some with HTTP?
See also [Putting EOSCTALHCB into Production](https://codimd.web.cern.ch/Q2d7McJXRkCMU6uI2nO6Ig#)
See [#55](https://gitlab.cern.ch/cta/operations/-/issues/55) ALICE instance in production
* Luca will release hardware mid-September
* Test migration mid-September
* **Wed 30 Sept.** `eosctaalicero` instance will be switched off and retired
* **Thu 1 Oct.** Switch off write access to CASTOR ALICE
* **Mon 5 Oct.** Block all access to CASTOR ALICE namespace, begin migration to CTA
* **Mon 12 Oct.** EOSCTA ALICE in production
* CASTOR T0ALICE will be returned to the ALICE pledge