Fix command 'cta-admin drive ls' not showing REPACK VO on mounts of type ARCHIVE_FOR_REPACK
Related ops issue:
Problem
When we run ta-admin dr ls, the VO for ARCHIVE_FOR_REPACK is wrongly reported as the VO of the tapepool. It should be the repack VO (currently named REPACK).
For example, these 3 archives are accounted on ALICE but should be on REPACK.:
cta-admin --json dr ls | jq -c '.[]|del(.driveConfig)' | grep REPACK | grep ARCHIVE{"logicalLibrary":"IBM1L9","driveName":"I1L90611","host":"tpsrv452","desiredDriveState":"UP","mountType":"ARCHIVE_FOR_REPACK","driveStatus":"TRANSFERRING","driveStatusSince":"9792","vid":"L92125","tapepool":"r_alice_raw","filesTransferredInSession":"2267","bytesTransferredInSession":"3935810422391","sessionId":"924601","timeSinceLastUpdate":"2","currentPriority":"0","currentActivity":"","ctaVersion":"4.10.1-1","devFileName":"/dev/nst0","rawLibrarySlot":"smc0","comment":"","reason":"","vo":"ALICE","diskSystemName":"","reservedBytes":"0","sessionElapsedTime":"9851","logicalLibraryDisabled":false,"physicalLibrary":""}
{"logicalLibrary":"IBM1L9","driveName":"I1L90614","host":"tpsrv459","desiredDriveState":"UP","mountType":"ARCHIVE_FOR_REPACK","driveStatus":"TRANSFERRING","driveStatusSince":"15411","vid":"L92619","tapepool":"r_alice_raw","filesTransferredInSession":"4020","bytesTransferredInSession":"6115764057814","sessionId":"924581","timeSinceLastUpdate":"15","currentPriority":"0","currentActivity":"","ctaVersion":"4.10.1-1","devFileName":"/dev/nst0","rawLibrarySlot":"smc3","comment":"","reason":"","vo":"ALICE","diskSystemName":"","reservedBytes":"0","sessionElapsedTime":"15451","logicalLibraryDisabled":false,"physicalLibrary":""}
{"logicalLibrary":"SPC2L9","driveName":"S2L91031","host":"tpsrv669","desiredDriveState":"UP","mountType":"ARCHIVE_FOR_REPACK","driveStatus":"TRANSFERRING","driveStatusSince":"7456","vid":"L94648","tapepool":"r_alice_raw","filesTransferredInSession":"2330","bytesTransferredInSession":"2260337391675","sessionId":"924621","timeSinceLastUpdate":"3","currentPriority":"0","currentActivity":"","ctaVersion":"4.10.1-1","devFileName":"/dev/nst0","rawLibrarySlot":"smc18","comment":"","reason":"","vo":"ALICE","diskSystemName":"","reservedBytes":"0","sessionElapsedTime":"7514","logicalLibraryDisabled":false,"physicalLibrary":""}RETRIEVE is fine:
{"logicalLibrary":"IBM460","driveName":"I4600811","host":"tpsrv069","desiredDriveState":"UP","mountType":"RETRIEVE","driveStatus":"TRANSFERRING","driveStatusSince":"9755","vid":"I44922","tapepool":"r_alice_raw","filesTransferredInSession":"1527","bytesTransferredInSession":"2512697030682","sessionId":"924603","timeSinceLastUpdate":"13","currentPriority":"0","currentActivity":"","ctaVersion":"4.10.1-1","devFileName":"/dev/nst0","rawLibrarySlot":"smc16","comment":"","reason":"","vo":"REPACK","diskSystemName":"eosctarepack","reservedBytes":"79683088438","sessionElapsedTime":"9809","logicalLibraryDisabled":false,"physicalLibrary":""}Research
In the origin of this problem it's the fact that these entries have the VO ALICE inserted in the table DRIVE_STATE, instead of REPACK.
These rows are inserted by OStoreDB::TapeMountDecisionInfo::createArchiveMount(...) which gets the VO not from a PotentialMount object passed by the caller, but from the destination tape VO (which will be the VO of the respective tape pool).
We can see the origin of the problem here:
Solution
Inside OStoreDB::TapeMountDecisionInfo::createArchiveMount(...), we should assign the default repack VO (instead of tape.vid) when the mount type is ArchiveForRepack.