-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
[Serve] allow gRPC deployment to use grpc context #41667
Conversation
Signed-off-by: Gene Su <e870252314@gmail.com>
Signed-off-by: Gene Su <e870252314@gmail.com>
Signed-off-by: Gene Su <e870252314@gmail.com>
Signed-off-by: Gene Su <e870252314@gmail.com>
Signed-off-by: Gene Su <e870252314@gmail.com>
Signed-off-by: Gene Su <e870252314@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
Signed-off-by: Gene Su <e870252314@gmail.com>
Signed-off-by: Gene Su <e870252314@gmail.com>
Signed-off-by: Gene Su <e870252314@gmail.com>
Docs build completed this time https://readthedocs.com/projects/anyscale-ray/builds/1885865/ not sure why it's showing failed here 😅 |
@edoakes would be nice if you have bandwidth to take a look at this one as well🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GeneDer question on the API here: from what I remember, when using vanilla gRPC the handler function will be passed the context
directly. Why not follow that paradigm instead of adding the get_grpc_context
API?
Bc that would be a breaking change given there are already users for gRPC proxy. Also I feel since there are already mechanisms for getting request metadata such as multiplex api, following that pattern is a better alternatives (than forcing users to take an gRPC context that they might not case about) |
You can make it an optional kwarg (I think that's what gRPC does to begin with). If user-provided functions take that kwarg, we pass it, else we don't. |
Signed-off-by: Gene Su <e870252314@gmail.com>
@edoakes @shrekris-anyscale I addressed all the comments PTAL and hopefully we can get this merged and cherry picked today🙏 |
Signed-off-by: Gene Su <e870252314@gmail.com>
This PR passes a grpc_context to deployments if the deployment uses it to get gRPC request related info can use to set code, details, trailing metadata, and compression. The original grpc._cython.cygrpc._ServicerContext type is not serializable, so we created a RayServegRPCContext to be able to pass to the deployment. Will follow up with doc change. --------- Signed-off-by: Gene Su <e870252314@gmail.com>
… (#41751) This PR passes a grpc_context to deployments if the deployment uses it to get gRPC request related info can use to set code, details, trailing metadata, and compression. The original grpc._cython.cygrpc._ServicerContext type is not serializable, so we created a RayServegRPCContext to be able to pass to the deployment. Will follow up with doc change. Why are these changes needed? Pick of #41667 --------- Signed-off-by: Gene Su <e870252314@gmail.com>
Why are these changes needed?
This PR passes a
grpc_context
to deployments if the deployment uses it to get gRPC request related info can use to set code, details, trailing metadata, and compression. The originalgrpc._cython.cygrpc._ServicerContext
type is not serializable, so we created aRayServegRPCContext
to be able to pass to the deployment. Will follow up with doc change.Related issue number
Closes #38616
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.