Requester pays with --mount with google-batch provider

[nkamitaki]

Thanks for developing such a useful tool for submitting jobs!

I think I have a similar issue as this one that was previously resolved, but as implemented for google-batch provider rather than google-cls-v2. Specifically, I am attempting to mount the same requester pays bucket referenced in that issue, but this appears to cause the job to fail fairly quickly after pulling images (judging by runtime) with no log output. Excluding the following line in the same dsub invocation runs and outputs a log until my script attempts to access the mounted bucket (generating an error from unbound variable as expected):

--mount CRAM_BUCKET=gs://fc-aou-datasets-controlled \

This dsub invocation with mounted requester pays bucket works successfully if I switch provider to google-cls-v2 and I'm able to mount other buckets successfully in google-batch, so I suspect this has to do with the requester pays characteristic. As the fix in that issue was resolved with an adjustment to google_v2_base.py (that google_cls_v2.py but not google_batch.py imports), I'm hopeful that a similar fix of passing user billing project somewhere in google_batch.py would work, but I am unfamiliar enough with the API to suggest any code.

Apologies for lack of additional log information - this is all I can think of to report as there doesn't seem to be more detail in either dstat (or gcloud batch jobs describe) to confirm this is the source of the problem.

Thanks!

[wnojopra]

Hi @nkamitaki ! Thanks for writing in.

Looking at the API docs for Volume there is a mountOptions field, which says For a Cloud Storage bucket, all the mount options provided by the gcsfuse tool are supported. Then in the page for gcsfuse options, billing-project is listed in the options. So we just need to pass along the project ID here in the mountOptions.

It would be this line that needs to be updated. The function would need to be updated to take in the user_project, and then it would be passed as an option along with the -o ro option. We'll add this to our list of updates for the next release.

[smlmbrt]

Has this been fixed in 0.5.1? I'm having the same problem (with the same bucket) as @nkamitaki.