Reduce restrictions imposed on repacked tape files being written to the CTA catalogue
Problem
As discussed in this CTA community post, repack will fail if owner_uid=0.
This is the desired behaviour for new files being archived: we don't allow files with owner_uid=0 to be registered in the CTA catalogue (the justification can be found here).
However, in case of imported tapes these values may end up in the catalogue anyway. If we need to repack these tapes, we should not be blocked by it.
For reference, this is the function preventing the tape file being written to the catalogue:
Discussion
Some ideas have been brought forward to prevent this problem from ever happening in the future...
Which one should we adopt?
- Prevent wrong tapefile metadata from being inserted into the CTA Catalogue.
- For this to work, we need ourselves to provide a tool to insert tape files into the catalogue.
- This solution may be too complicated, as we can't guarantee that it works for all site that want to migrate to CTA in the future.
- Validate tapefile metadata after it has been inserted in the CTA Catalogue.
- We could provide a consistency-check tool. For example, with the same checks as
checkTapeFileWrittenFieldsAreSet. - This is easier to implement.
- Allow repack to go forward even if tapefile metadata restrictions are not met.
- Very simple to implement, but allowing tape files to be imported without restriction may cause other problems in the future.
Edited by Joao Afonso