-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support "Requester-Pays" billing in google-cloud-nio #4828
Comments
@jean-philippe-martin It's looking like @Horneth won't have time to implement this in the short-term future -- since you mentioned that the change was fairly simple, would you be able to submit a PR yourself? We'd be happy to help review. |
A few thoughts on this: One important thing to be aware of about RP is that specifying the billing project in the request to GCS incurs cost to the requester even if the bucket does not have requester pays enabled.
Or, NIO could implement one of those 2 options itself so that it's transparent to the user but they have less control (in which case I would favor option 1 over 2). |
@Horneth Ideally we'd just check up-front whether the bucket has requester pays enabled, and specify the user's default project as the billing project if it is. It would also be good, I think, if we included a toggle that allows the client to tell the library to throw and refuse to proceed if an attempt is made to access requester-pays data, so that users who don't want to incur GCS access charges can get a hard guarantee that they won't. |
@jean-philippe-martin has added support for requester pays to gcloud. I've set up a new fork of the project at https://github.com/broadinstitute/google-cloud-java. I have a branch https://github.com/broadinstitute/google-cloud-java/tree/lb_update_pom_to_publish_to_orgbroad which I believe should make the changes necessary to run on dataproc and avoid googleapis/google-cloud-java#2453. However, if you rollback the dependencies the project no longer compiles. You can compile the nio-subproject, but the parent project can no longer build against the old dependencies. That makes me very nervous because it seems likely that we will encounter runtime errors if we substitute them. JP created a small test case to reproduce the error and it seems like the dataproc team is looking at it. Hopefully they can resolve the issue and we can switch to the base library instead of needing to publish an additional sketchy version of it. |
This was done -- closing. |
No description provided.
The text was updated successfully, but these errors were encountered: