Status Updates and Round Table
ATLAS Commissioning Tests (Julien)
SFO Test
- EOSCTA ATLAS production instance: instance reset, objectstore and catalogue were wiped, updated and recreated.
- PPS instances for ATLAS and CMS: upgraded to CTA v2.0-1 in preparation for ATLAS SFO test and starting write tests with CMS.
- LTO drives added to ATLAS PPS in preparation for SFO test.
- Everything is ready from our side for the ATLAS SFO test. The CTA - SFO tests document describes the plan for the tests.
- We have asked ATLAS to start a 2GB/s test tonight from SFO. (Communication is difficult in current situation, and we may need to be flexible about exactly when they start the tests).
Simultaneous write/recall/delete test
- We are prepared, waiting for ATLAS to be ready to send us data. Hopefully next week.
Other tests
- Dual-copy tape pool test to be scheduled after above tests have been done.
Tape Pool Statistics and Monitoring (Cédric)
- cta-statistics-save tool is almost finished. The statistics are computed, need to be saved in the MySQL tape statistics DB.
- This will be executed as a RunDeck job for now. Cédric will get it working and document the procedure on eoscta mkdocs site. Later we can review if we want to change the procedure so we don't have to rely on RunDeck.
- How to handle failures? Failed processes in RunDeck save errors written to stdout. So we should write the statistics we were trying to save there (e.g. in JSON format) in case we need to recover from a failure.
- The replacement for ACRON is called ACRON_NEXT. It uses RunDeck in the back-end. There was a status update in ASDF recently: ACRON_NEXT
Garbage Collector (Steve)
- We had a discussion earlier in the week about the garbage collector. Detailed notes from this discussion are available on the mkdocs site.
Operational Readiness (Michael)
- We need to consider what it will mean if we need to take CTA to production in the current lockdown/teleworking situation. Some issues will be complicated, for example training the tape operators. Everyone to think about what challenges we need to think about. We will have a full discussion on this next week, hopefully with Vlado present.
External Sites (Michael)
- The tapeoperations mkdocs site is for CERN-specific procedures and information and is only visible inside CERN. The eoscta mkdocs site will contain documentation for developers and systems integrators and will be visible externally. Michael will reorganise the information on the two sites so this is the case.
- We had a request from the dCache developers for binary RPMs for CTA. This is difficult to provide to external organisations due to dependencies on CERN-specific RPMs. Our current policy is to give access to source, so external orgs can build it themselves, but we will not provide RPMs. This policy can be looked at again after we are in production.
- David Jericho (AARNET, Australia) is going to put a proposal forward to the Head of Architecture and the CloudStor product owner, to adopt CTA as their archival system of choice. Their current capacity needs are in the order of a few hundred TB. A future service direction will expand that to a target of approximately 100 PB to their research communities. He is going to build and configure CTA from source and has offered to contribute documentation.
CMS Schedule and LHC Schedule (Michael, Oliver)
- At the Crisis Management meeting on Tuesday, it was mentioned that all LS2 upgrade activity has been stopped. It remains to be seen what the impact will be on the LHC schedule. From our side we will not make any changes to our CASTOR to CTA migration schedule, so we will be ready for Run-3 in any event.
- At the CMS meeting on Wednesday, they said that they hoped to have migrated from Phedex to Rucio by end of this year. Our plan is to migrate CMS to CTA before the end of the year, so it is possible that if their their migration is late, it will impact on our schedule, as we do not want to invest time and effort on integrating CTA with Phedex.
- From our side we need to press ahead with tests with CMS: write tests, CASTOR migration test, read of migrated data test. We plan to start this activity in April.