Support custom client protobufs in grpc server #1420
Comments
|
With the new executor in master which is in golang this option becomes more likely. Be interesting to discuss how this would be done. I see golang's v2 protobufs allow more dynamic usage: golang/protobuf#199 |
|
Thoughts on possibly allowing the serialized proto message all the way to the method implementations? |
|
This should already be possible with the latest master as the http protocol is passed through as binary in the executor. So if you launched a pod that could decode the message it should work. |
|
Gotcha, I mistook I stumbled across an Envoy blog post here that discusses the tradeoffs between using |
|
@cliveseldon let me know if you have any specific preferences in terms of this implementation. I can try to take a crack at it if we're okay iterating a bit. |
|
So let me summarize the proposed solution to see if I understand:
|
|
That covers it. I don't see a clean way to make the executor aware of the type URLs as of yet, so it would just be updated protos for the executor. |
Adds custom protobuf support to the Seldon protobuf specification using the `Any` proto type. Addresses SeldonIO#1420
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses SeldonIO#1420 Signed off by Nick Groszewski (<[email protected]>)
Additional `customData` field added to the prediction protobuf, as well as updates to the python package to properly pass the raw protobuf section down to the `user_model` implementation. Addresses #1420 Signed off by Nick Groszewski (<[email protected]>)
|
The PR is merged so closing. |
We have been using gRPC internally for most of our models for quite some time, so they already have protobufs that are specific to each model's features. We would like to maintain the strong type safety provided by these custom protobufs across all of our models.
The text was updated successfully, but these errors were encountered: