-
Notifications
You must be signed in to change notification settings - Fork 4.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
Add filters for Buf Connect RPC protocol. #24836
Conversation
Hi @jchadwick-buf, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
@mattklein123 appreciate you taking the time to chat with us today and maybe sponsor this contribution. @jchadwick-buf is going to highlight areas of the diff which could use a maintainer's eye and point out the few areas where we still have a little work to do. |
source/extensions/filters/http/connect_grpc_bridge/end_stream_response.cc
Outdated
Show resolved
Hide resolved
source/extensions/filters/http/connect_stats/connect_stats_filter.cc
Outdated
Show resolved
Hide resolved
source/extensions/filters/http/connect_stats/response_frame_counter.cc
Outdated
Show resolved
Hide resolved
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.
At a high level this makes sense. I left some comments and I'm happy to sponsor. Thanks.
/wait
source/extensions/filters/http/connect_grpc_bridge/end_stream_response.cc
Outdated
Show resolved
Hide resolved
source/extensions/filters/http/connect_stats/connect_stats_filter.cc
Outdated
Show resolved
Hide resolved
source/extensions/filters/http/connect_stats/response_frame_counter.cc
Outdated
Show resolved
Hide resolved
200619f
to
b983ece
Compare
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
- Merges connect_stats with grpc_stats. - Merges unary+streaming filters in connect-grpc bridge. - Moves to using Protobuf Struct for JSON encoding/decoding. - Improves coverage of test suite. Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
gRPC requires the :te header to be set to trailers. It was missing for the streaming case, which didn't bother gRPC-go, but it did break grpcpp. Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
f9b6e1b
to
21930ca
Compare
Signed-off-by: John Chadwick <jchadwick@buf.build>
21930ca
to
271aaa9
Compare
I don't know why it says I added and then removed reviewers: I didn't, I only hit "Ready for Review." In any case, I think this is ready for review now. I've tested it in many scenarios and I've tried to cover the code with an adequate amount of tests. If desired, I can split this into more PRs, merge/rebase commits, etc. I tried to avoid too much rebasing for the moment so that the progres/changes were not obscured. |
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.
Thanks for your contribution!
I'm not sure if this should be part of contrib or extensions. @mattklein123 do you have any take on this?
|
||
// If true, the filter will instrument `Buf Connect <https://connect.build/>` protocol messages in | ||
// addition to gRPC. | ||
bool enable_buf_connect_support = 6; |
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.
I might be missing something here, but the filter is for GrpcStats, and Buf-Connect is a different protocol, so shouldn't there be a BufConnectStats filter (that has the relevant config)?
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.
What we wound up doing was merging Buf Connect support into the gRPC stats filter due to the overlap between the protocols. (Connect is semantically compatible with gRPC, so it's somewhat akin to say, gRPC-web.) I'm open to trying to make this make more sense. Context: #24836 (comment)
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.
Given the similarity of the protocols I think it's reasonable to have it be part of this filter. We can potentially make this more clear in the docs. I will take a look.
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.
Is there any reason to actually have this be configurable? It's turned on by content-type, right? Can we just turn it on automatically and then just document that it is supported somewhere in the top level filter documentation?
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.
Done.
Sorry for the review delay. I will get back to this within the next week. |
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.
Thanks at a high level this LGTM. Given the alpha status I think it's fine to ship and iterate with some real customers.
Note that if we want to call this eventually robust to untrusted data we should have some limited fuzzing of all of the relevant parsing code. This can be done later.
Thank you!
/wait
|
||
// If true, the filter will instrument `Buf Connect <https://connect.build/>` protocol messages in | ||
// addition to gRPC. | ||
bool enable_buf_connect_support = 6; |
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.
Is there any reason to actually have this be configurable? It's turned on by content-type, right? Can we just turn it on automatically and then just document that it is supported somewhere in the top level filter documentation?
@@ -0,0 +1,11 @@ | |||
.. _config_http_filters_connect_grpc_bridge: |
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.
Can you also update relevant docs here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/grpc
And ref link back to this filter where appropriate.
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.
I just now added the bridge to the list, is that what you mean? Or should it have a section just for connect?
namespace Envoy { | ||
namespace { | ||
|
||
class ConnectIntegrationTest : public testing::TestWithParam<Network::Address::IpVersion>, |
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.
Can you have an integration test for the actual end to end flow for both unary and streaming?
In general can you also check the code coverage report and make sure you are reasonably covering all of the code?
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.
Done.
I did try to ensure the important cases are covered, and we have >96% on everything. We can aim for 100% if you would prefer though. I think the main tricky case is trying to find a way to get WKT JSON encoding to fail.
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
Signed-off-by: John Chadwick <jchadwick@buf.build>
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.
Great, thanks!
Thanks! Github says workflows need approval still. Did I need to do something there? |
Signed-off-by: John Chadwick jchadwick@buf.build
Implements two Connect filters:
connect_stats
: Similar togrpc_stats
. Counts messages and success/failure as stats.connect_grpc_bridge
: Provides a bridge from Connect clients to gRPC servers.The Buf Connect protocol provides similar features to gRPC, but supports simple HTTP/1.1 requests for unary procedure calls and does not require trailers for streaming procedure calls.
The stats filter is similar to
grpc_stats
, as mentioned prior. It could potentially be rolled intogrpc_stats
, although the Connect protocol does differ from gRPC in a fair few ways, so I do anticipate the resulting code would be a little hard to follow. The bridge filter is not exactly analogous to any existing gRPC filters. For streaming Buf Connect requests, it is somewhat similar to thegrpc_web
filter, but for unary Buf Connect requests, it's more similar togrpc_http1_bridge
.The bridge filter is mainly useful for customers who are interested in transitioning to using Connect incrementally, whereas the stats filter is useful for anyone who wants to ensure that their stats covers usage of the Connect protocol, either independently or in addition to gRPC.
Closes #22679.