Add new support for repack archive routes
Problem
As shown in https://gitlab.cern.ch/cta/operations/-/issues/1310 and other issues, there is currently no way to separate repack archive requests from user archive requests regarding the destination tape pool.
This means that, during a repack, old files that are being queued and written to a new tape may get mixed with new files that have just been queued by users of the same VO.
This is an undesirable behaviour that may end up causing issues (for example performance) when reading very different types of files from the same tape. It is also the latest blocker from completely separating the CTA operation domain from user domain.
More info can be found here on slide 23:
Solution
Part 1 (CTA catalogue)
- Add a new
REPACK_TAPE_POOL_ID
column to theARCHIVE_ROUTE
. - This column should be optional (nullable), be a foreign key to
TAPE_POOL_ID
andUNIQUE
(together withSTORAGE_CLASS_ID
).
Part 2 (CTA code)
- Create the new
cta-admin
options to set/modify theREPACK_TAPE_POOL_ID
column. - Modify the maintenance process code to pick up the
REPACK_TAPE_POOL_ID
value (instead of the default one) when archiving repack files.- If the (optional) repack tapepool value is not defined, use the default
TAPE_POOL_ID
. - Parts of this code can be found here:
- If the (optional) repack tapepool value is not defined, use the default