Conflict between CSV delivery option and CLI download directory -d/--dir
Description
There is an architectural and functional conflict between the delivery: <acacia || scratch || dug> parameter specified in the input CSV file and the -d DIR / --dir DIR command-line option in the manta-ray-client.
Currently, the client does not gracefully handle situations where these two options point to physically distinct file systems or compute environments (e.g., trying to deliver to a remote storage cluster like dug while setting a local download directory like -d /scratch/foo on a high-performance computing system like Setonix). The client cannot cross-mount or automatically migrate files between these disparate server-side and client-side locations, leading to silent failures, errors, or unexpected behavior.
Steps to reproduce / scenario:
1 Define delivery=scratch or (dug/acacia) inside the job submission CSV file
2 Run the manta-ray-client passing a local directory path that doesn't natively map to the server's delivery destination via the CLI:
manta-ray-client --csv input.csv -d /path/to/custom/local/scratch
3 Observe that the client fails to fetch/move the data correctly because it assumes a shared file system structure that may not exist, or it attempts an impossible server-to-local filesystem bridge.
Expected behaviour
The client should either:
- Validate and warn/fail early: Catch the conflict before initiating the job or download process, informing the user that the
-d option and the CSV delivery destination are incompatible
- Override logic: Clearly define a hierarchy (e.g. if
-d is provided, it explicitly overrides certain delivery behaviours, or vice versa, if that aligns with the ASVO architecture).
- Graceful error handling: Provide a clear error message explaining why the download cannot proceed across the specified boundaries
To do
Conflict between CSV
deliveryoption and CLI download directory -d/--dirDescription
There is an architectural and functional conflict between the delivery: <acacia || scratch || dug> parameter specified in the input CSV file and the -d DIR / --dir DIR command-line option in the manta-ray-client.
Currently, the client does not gracefully handle situations where these two options point to physically distinct file systems or compute environments (e.g., trying to deliver to a remote storage cluster like dug while setting a local download directory like -d /scratch/foo on a high-performance computing system like Setonix). The client cannot cross-mount or automatically migrate files between these disparate server-side and client-side locations, leading to silent failures, errors, or unexpected behavior.
Steps to reproduce / scenario:
1 Define
delivery=scratchor (dug/acacia) inside the job submission CSV file2 Run the
manta-ray-clientpassing a local directory path that doesn't natively map to the server's delivery destination via the CLI:manta-ray-client --csv input.csv -d /path/to/custom/local/scratch3 Observe that the client fails to fetch/move the data correctly because it assumes a shared file system structure that may not exist, or it attempts an impossible server-to-local filesystem bridge.
Expected behaviour
The client should either:
-doption and the CSVdeliverydestination are incompatible-dis provided, it explicitly overrides certain delivery behaviours, or vice versa, if that aligns with the ASVO architecture).To do
manta-ray-clientparses the CSVdeliveryfield in tandem with the-dCLI argumentdeliveryoption be made optional if-dis used? Or should the client explicitly throw aValidationErrorwhen they clash?