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:
The option discussed above (adding a new REPACK_TAPE_POOL_ID column) may lead to some ambiguity and makes it difficult to implement important constraints.
Examples of problems:
It does not clearly state that if REPACK_TAPE_POOL_ID is NULL, the tape pool decision should fallback to TAPE_POOL_ID.
It makes it very difficult to guarantee that all tape pools associated with a single STORAGE_CLASS_ID are unique (both from REPACK_TAPE_POOL_ID and TAPE_POOL_ID).
Therefore I propose a different solution:
Add 2 new columns to the ARCHIVE_ROUTE table, both CHAR(1) (boolean) and NOT NULL:
ENABLED_FOR_USER
ENABLED_FOR_REPACK
At least one of them must be set to 1 for any row.
Checking the archive routes for a storage class becomes very simple!
We just need to filter by ENABLED_FOR_USER or ENABLED_FOR_REPACK depending on the request type.
Complete SQL definition (new lines marked with >):
Considering that the deployment of the solution described above posed some problems to production, I will present here a few different alternatives, with their pros and cons.
Constraints
First, these are the requirements that must be respected:
All Archive Routes associated with a single Storage Class must reference different Tape Pools.
At the moment, this is enforced by the constraint UNIQUE(STORAGE_CLASS_ID, TAPE_POOL_ID).
The transition to using Repack Archive Routes (whatever the chosen implementation) must be seamless. In particular this means:
At no moment can be an archive request be left without an Archive Route. Any changes to the Archive Routes must leave no temporal gaps (even if short) where archiving files are left without a destination. Examples:
During CTA Catalogue migration from v14.0 to v15.0.
During CTA RPM update.
During setup/modification of User/Repack Archive Routes.
At the moment, Archive Routes are uniquely identified by STORAGE_CLASS_ID and COPY_NB (composite primary key). Any updates to the CTA Catalogue Schema (ex: modifying the primary key) must take this into consideration, so that no versions of CTA touching Catalogue v15.0 get broken.
We should should avoid any bad practices when modifying the CTA Catalogue Schema. This includes poor normalisation in DB design.
Options
1. (Nope) Add a new column REPACK_TAPE_POOL_ID
In order to be backward compatible, this column must be optional and have a default value of NULL.
If its value is NULL, the Repack Tape Pool should be selected from TAPE_POOL_ID instead of REPACK_TAPE_POOL_ID,
Problems:
Because of the NULL value, I can't add a constraint such as UNIQUE(STORAGE_CLASS_ID, REPACK_TAPE_POOL_ID). This means that the new REPACK_TAPE_POOL_ID will have much weaker guarantees than TAPE_POOL_ID.
The behaviour that a NULLREPACK_TAPE_POOL_ID should default to TAPE_POOL_ID is not clear by looking at the schema.
2. (Nope) Add new boolean columns ENABLED_FOR_USER and ENABLED_FOR_REPACK
Both these columns will be CHAR(1) (boolean) and NOT NULL.
At least one of them must be set to 1 for any row.
Columns added to the primary key, so that we can reference all rows and guarantee the uniqueness of each Archive Route.
Problems:
The primary key needs to be modified to include ENABLED_FOR_USER and ENABLED_FOR_REPACK.
Selecting entries on the table (add, ch, rm) might become cumbersome and unclear. We probably need 4 keys.
When adding a new row for repack, we need to first disable ENABLED_FOR_REPACK from any previously existing archive route. This may open a gap when there is no Archive Route for repack requests, with the risk of loosing data.
3. (Recommended) Add a new string column ARCHIVE_ROUTE_TYPE or TYPE
Of type VARCHAR(100).
Constrained to only accept the values DEFAULT, USER and REPACK.
USER is selected for user archive requests and REPACK for repack archive requests.
If one of these is not defined, it falls back to DEFAULT.
Column added to the primary key.
Advantages:
By default, the old archive routes should get the value DEFAULT. This makes the intent of the field very clear.
New rows will take precedence over it DEFAULT. The transition to a new Archive Route leaves no gap for archive requests to get lost.
By looking into the table we can get a very clear idea of the intent.
It can be expanded in the future for more values.
Simple interface:
cta-admin add/ch/rm will require an extra mandatory argument:
type or archive_route_type, with values USER/REPACK/DEFAULT.
Joao Afonsochanged title from Add new {--}repack{-_-}tape{-_-}pool{-_id-} option to the archive_route table to Add new repacktapepool option to the archive_route table
changed title from Add new {--}repack{-_-}tape{-_-}pool{-_id-} option to the archive_route table to Add new repacktapepool option to the archive_route table
Joao Afonsochanged title from Add new repack tapepool option to the archive_route table to Add new repack tapepool field to the archive_route table
changed title from Add new repack tapepool option to the archive_route table to Add new repack tapepool field to the archive_route table