FTS update Room: 31/S-023 * FTS team: feedback on: - meeting with LHCb on 27 Nov - schedule for release of FTS/gfal ("query prepare" feature and "check m-bit" feature) * Michael: feedback on status of LHCb T1s wrt. support for XRootD TPC

CTA test status Room: 31/S-023 * The repack test was launched with 4 tapes and 6 drives in order to have max bandwidth. The test failed as the buffer ran out of space. Cédric has done some analysis (issue [#681](https://gitlab.cern.ch/cta/CTA/issues/681)) and identified three issues. * Julien: feedback on simple rate limiter test * Julien: feedback on full-scale test with ATLAS/Rucio/FTS multi-hop

DB Schema Versioning Room: 31/S-023 * Steve: Update on CTA DB schema v1.0 * Cédric: Update on tools for DB schema versioning/validation/update schema

CTA version 1.0 Room: 31/S-023 * I propose we freeze all new CTA features for version 1.0. (No more commits to master which add features to core CTA software). * Are there any bugs which need to be fixed for v1.0? * EOS version: is there anything we need which is not in our current EOS version? - delete on CLOSEW * Release schedule (v1.0 branch, tagging, RPMs, etc.)

Documentation Room: 31/S-023 * CTA/doc/ directory has been reorganised into **ConferencePapers**, **Presentations**, **DevelopmentNotes**, **CASTOR**, plus the developer documentation. * The developer documentation is mainly split across 3 PDFs (cta.pdf, EOSCTA.pdf, CASTOR TapeServer.pdf) which Eric will synthesise this into One PDF to Rule Them All. * The operational documentation (Twiki, CTA Admin guide, some MD docs) has been consolidated on the [internal mkdocs site](https://tapeoperations.docs.cern.ch/). Vlado will progressively update this. * In future the non-CERN specific parts of the documentation will be moved to the [external mkdocs site](https://eoscta.docs.cern.ch/) * Michael: Update on CTA logo and website

Monitoring Room: 31/S-023 * tsmod-daily-report: Moving checks to CTA (issue [#678](https://gitlab.cern.ch/cta/CTA/issues/678)) is a prerequisite for ATLAS migration. Implementing as a dahboard instead of e-mails (issue [#677](https://gitlab.cern.ch/cta/CTA/issues/677)) can be done as a later refinement. For ATLAS migration I propose we implement the CTA daily report as an e-mail. * Alarm system: Disabling tapes and drives is done. Disabling libraries is not a requirement for migration. The alarm system was de-daemonized and runs via Rundeck. i.e. Alarm system is ready for ATLAS migration. **Dashboards** We currently have the following dashboards: * [meter-cta.web.cern.ch](https://meter-cta.web.cern.ch/): empty dashboard with no data sources * [monit-grafana.cern.ch/d/000000116/host-metrics](https://monit-grafana.cern.ch/d/000000116/host-metrics?orgId=1&var-availability_zone=All&var-bin=$__auto_interval_bin&var-environment=All&var-hostgroup=tapeserver&var-hostgroup=tapeserver%2Fibm1l8&var-hostgroup=tapeserver%2Fibm355&var-hostgroup=tapeserver%2Fibm360&var-hostgroup=tapeserver%2Fibm3jd&var-hostgroup=tapeserver%2Fibm455&var-hostgroup=tapeserver%2Ft10kd6&var-hostname=All&var-rp=one_week): host metrics for tape servers * [monit-grafana.cern.ch/d/19Z7vUMmk/timings-in-house](https://monit-grafana.cern.ch/d/19Z7vUMmk/timings-in-house?orgId=29): CTA timings and metrics * [monit-grafana.cern.ch/d/5tAh216mk/read-write-throughput-cta](https://monit-grafana.cern.ch/d/5tAh216mk/read-write-throughput-cta?orgId=29&var-vo=atlas&var-vo=cms&var-clientHost=All): Realtime tape I/O performance * [filer-carbon.cern.ch/grafana/d/000000036/eos-control-tower](https://filer-carbon.cern.ch/grafana/d/000000036/eos-control-tower?orgId=1): EOS Control Tower (filter by EOSCTA instance) * [monit-grafana.cern.ch/d/dfpOzRnmz/data-volume](https://monit-grafana.cern.ch/d/dfpOzRnmz/data-volume?orgId=29): Data Volume, (including "Frédéric’s plot”), both CASTOR + CTA (scroll down for CTA) * [monit-grafana.cern.ch/d/rgcoo0vmk/tape-stats-by-density-history-castor-cta](https://monit-grafana.cern.ch/d/rgcoo0vmk/tape-stats-by-density-history-castor-cta?orgId=29): Tape stats by density, both CASTOR + CTA * [monit-grafana.cern.ch/d/000000786/infrastructure-castor-and-cta](https://monit-grafana.cern.ch/d/000000786/infrastructure-castor-and-cta?orgId=29): Infrastructure, both CASTOR + CTA * [monit-grafana.cern.ch/d/obWK_dAik/tape-pools-statistics](https://monit-grafana.cern.ch/d/obWK_dAik/tape-pools-statistics?orgId=29): CTA tape pool statistics (Anything else not on this list?) Questions: 1. Who are the audiences for these various dashboards (CTA devops, tape operators, management, ...?) 2. Is there anything missing which we need to go into production? - A dashboard like the one for CASTOR Stager activity - anything else? 3. How should we reorganise the dashboards?

CASTOR PUBLIC Room: 31/S-023 * Handover of CASTOR to TAB section is planned for January 2020. * CASTOR ‘backup’ disk pool will lose 14 servers in March 2020, leaving 4 servers. * There are 7 users of the ‘backup’ service class (= ‘backup’ disk pool by configuration). The biggest users are internal to IT (EOS, AFS, HADOOP). * The bandwidth is irregular, with spikes at 2GB/s **Proposal** Migrate those 3 to a new CTA backup instance before end of March. We can then decommission the 14 oldest disk servers and still serve the other customers with the remaining 4 servers. Would existing backup data be migrated or would it be let to expire? * If migrated, need to separate/repack tapes to be migrated vs. those that will stay (~14 PB) * If expired, clients will need to access both the old and the new endpoint. For old backups, sufficient disk capacity for retrieval would have to be kept on CASTOR. And expiry may be far in the future or not exist at all (this is controlled by the clients). **Problems to be solved** * Management of encryption keys

Space-aware GC Room: 31/S-023 * Steve: update on space-aware garbage collector for ALICE

AOB Room: 31/S-023 * Date of section lunch: Tue 17 Dec