-
Notifications
You must be signed in to change notification settings - Fork 827
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
Rust SDK: Add passthrough openssl feature #1202
Conversation
Grpc-rs depends on boringssl by default which can conflict with crates that depend on openssl. Newer versions of grpc-rs expose an "openssl" feature to optionally use openssl instead. To make Agones' Rust SDK compatible with openssl, this bumps the grpc-rs dependency version and adds "openssl" and "openssl-vendored" features that simply forward to grpc-rs. Fixes googleforgames#1201
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rib The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Build Failed 😱 Build Id: 85facb9d-0b93-424f-a820-6c05b7ce2917 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
@googlebot I signed it! |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
Thanks for the PR! Looks like there are issues with the conformance tests. Are you finding your changes are working locally? |
hmm, I had only tested that things compiled and assumed initially there would be no semantic changes for grpc-rs 0.4, but testing rust-simple here I see these errors now:
which I don't have if I revert that change, so I guess porting to 0.4 will be more involved somehow :/ sorry for jumping the gun here. |
No worries at all - in theory, with gRPC, there should be no issue. But Rust gRPC apparently may have some issues. Might be worth checking in with the rust-rs team, see if they know what's up. |
We recently updated gRPC, and I noted there is a 0.4.7 of grpcio, wondering if the combination will solve this problem? Wondering if you would like to take this up again? |
Thanks for the update. I ended up using Tonic for handling gRPC and interfacing with Agones' I might be able to help provide a Tonic based example if that would be useful? |
Given we have a client layer in front of the grpc implementation, we could switch out gRPC implementations (I counted 4 of them in Rust at last Google), without breaking anything. If there is a specific one that is clearly better than the rest, it may be worth making the switch in the official Rust client? |
Asking around a bit, it sounds like Tonic is the most lauded grpc implementation in Rust. It sounds like it might be worth starting a ticket on migrating our SDK to Tonic, and then doing the implementation! |
Yeah, I've been really happy with Tonic and the maintainer is really responsive on Discord which has been great too. When it comes to defining an SDK I'd perhaps be weary of stabalising anything for Rust too soon. Quite a bit is in flux at the moment within the Rust ecosystem given that async/await only stabilised in November. Considering how useful they for network services I'd assume projects like grpc-rs will overhaul their api at some point to work in terms of async futures. Even though Tonic is one of the more mature grpc implementations, it's still only at a 0.1 version and the maintainer will be breaking the api soon as he iterates for 0.2. For game servers interacting with the Agones sidecar then I currently tend to think it's enough to provide the sdk.proto gRPC interface. Considering how simple the interface is vs how varied game engines might be then maybe just providing a variety of examples in different languages is enough? I suppose if you're set on having a stable Rust SDK then it might at least be best to constrain it to only work with the Tokio runtime for now (Tonic is built on Tokio and a library called Tower). Any stability should probably just be provided on a best-effort basis though, since Tonic isn't stable yet. |
So TL;DR:
Sound good to everyone? |
Closing the PR! Will come back to the Rust ecosystem in a bit. Ticket filed: #1300 |
Grpc-rs depends on boringssl by default which can conflict with crates
that depend on openssl.
Newer versions of grpc-rs expose an "openssl" feature to optionally use
openssl instead. To make Agones' Rust SDK compatible with openssl, this
bumps the grpc-rs dependency version and adds "openssl" and
"openssl-vendored" features that simply forward to grpc-rs.
Fixes #1201