Protobuf indirection mapping header#1236
Conversation
Needed for Google import. This is only part way implemented, looking for early feedback before committing to this approach. Thanks!
|
Fine with me if fine for other G folks. |
fengli79
left a comment
There was a problem hiding this comment.
LGTM to the WIP in general.
Can we tests to check:
- No #include for protobuf headers out of common/protobuf folder.
- No ::google::protobuf out of common/protobuf folder.
include/envoy/grpc/async_client.h
Outdated
|
|
||
| #include "common/protobuf/descriptor.h" | ||
|
|
||
| #include "google/protobuf/descriptor.h" |
There was a problem hiding this comment.
This and the rest are not done yet as it's WiP - I'll be cleaning up all these refs, thanks.
| @@ -62,19 +63,17 @@ class JsonTranscoderConfig : public Logger::Loggable<Logger::Id::config> { | |||
| google::protobuf::io::ZeroCopyInputStream& request_input, | |||
There was a problem hiding this comment.
Protobuf::Io::ZeroCopyInputStream
| google::protobuf::util::Status | ||
| methodToRequestInfo(const google::protobuf::MethodDescriptor* method, | ||
| google::grpc::transcoding::RequestInfo* info); | ||
| google::protobuf::util::Status methodToRequestInfo(const Protobuf::MethodDescriptor* method, |
| google::grpc::transcoding::RequestInfo* info); | ||
|
|
||
| private: | ||
| google::protobuf::DescriptorPool descriptor_pool_; |
|
|
||
| void RpcChannelImpl::CallMethod(const ::google::protobuf::MethodDescriptor* method, | ||
| void RpcChannelImpl::CallMethod(const Protobuf::MethodDescriptor* method, | ||
| ::google::protobuf::RpcController*, |
| void RpcChannelImpl::CallMethod(const Protobuf::MethodDescriptor* method, | ||
| ::google::protobuf::RpcController*, | ||
| const ::google::protobuf::Message* grpc_request, | ||
| ::google::protobuf::Message* grpc_response, |
| // ::google::protobuf::RpcChannel | ||
| void CallMethod(const ::google::protobuf::MethodDescriptor* method, | ||
| void CallMethod(const Protobuf::MethodDescriptor* method, | ||
| ::google::protobuf::RpcController* controller, |
| void CallMethod(const ::google::protobuf::MethodDescriptor* method, | ||
| void CallMethod(const Protobuf::MethodDescriptor* method, | ||
| ::google::protobuf::RpcController* controller, | ||
| const ::google::protobuf::Message* grpc_request, |
| void CallMethod(const Protobuf::MethodDescriptor* method, | ||
| ::google::protobuf::RpcController* controller, | ||
| const ::google::protobuf::Message* grpc_request, | ||
| ::google::protobuf::Message* grpc_response, |
| Http::AsyncClient::Request* http_request_{}; | ||
| const ::google::protobuf::MethodDescriptor* grpc_method_{}; | ||
| const Protobuf::MethodDescriptor* grpc_method_{}; | ||
| ::google::protobuf::Message* grpc_response_{}; |
|
@fengli79 Good idea on automated validation on dependencies. I'll add a |
|
@mattklein123 @dnoe @lizan @fengli79 This is now ready, PTAL. |
mattklein123
left a comment
There was a problem hiding this comment.
looks good, 2 small comments, also needs master merge FYI
| @@ -0,0 +1,33 @@ | |||
| #pragma once | |||
There was a problem hiding this comment.
Can we get some comment/explanation in this file of why we have this?
tools/check_format.py
Outdated
| SUFFIXES = (".cc", ".h", "BUILD") | ||
|
|
||
| # Files in these paths can make reference to protobuf stuff directly | ||
| GOOGLE_PROTOBUF_WHITELIST = ('./ci/prebuilt', './source/common/protobuf') |
There was a problem hiding this comment.
small ask: This is going to cause issues for us in our import. Would it be possible to do this as a regex somehow where it will match an arbitrary prefix? Or allow the prefix to be passed as a new CLI option?
| namespace Envoy { | ||
|
|
||
| namespace Protobuf = google::protobuf; | ||
| namespace ProtobufWkt = google::protobuf; |
|
|
||
| typedef std::string String; | ||
|
|
||
| inline const String ToString(const std::string& s) { return s; } |
There was a problem hiding this comment.
I know the backstory so I understand why this exist but it's pretty weird looking without this context. I'm assuming as written here that it is effectively a no-op with optimizations on.
There was a problem hiding this comment.
Yes, this is my assumption, today it's not used for anything on the performance critical path either.
tools/check_format.py
Outdated
|
|
||
| # To avoid breaking the Lyft import, we just check for path inclusion here. | ||
| def whitelistedForProtobufDeps(file_path): | ||
| return len([prefix in file_path for prefix in GOOGLE_PROTOBUF_WHITELIST]) > 0 |
There was a problem hiding this comment.
nit: s/prefix/path_segment
Right? (Just making sure I'm reading this correctly).
Automatic merge from submit-queue. Remove pessimizing move.
Description: this PR fixes the android release job and caches the release artifacts to prevent double unnecessary compute time. Risk Level: med - confirm working with release tag. Testing: testing done in #1236. However, we will need to cut a release to verify final correctness Signed-off-by: Jose Nino <jnino@lyft.com> Signed-off-by: JP Simard <jp@jpsim.com>
Description: this PR fixes the android release job and caches the release artifacts to prevent double unnecessary compute time. Risk Level: med - confirm working with release tag. Testing: testing done in #1236. However, we will need to cut a release to verify final correctness Signed-off-by: Jose Nino <jnino@lyft.com> Signed-off-by: JP Simard <jp@jpsim.com>
**Description** This consolidates the extproc admin server from two separate ports (metricsPort and healthPort) into a single adminPort (default 1064) serving both /metrics and /health endpoints. The `aigw run` and the new `aigw healthcheck` commands now take --admin-port flags, propagating this to extproc. Previously, extproc exposed metrics on port 1064 and health checks on port 1065. Now both are served from a single HTTP server on port 1064, simplifying configuration and Docker HEALTHCHECK setup. The Docker HEALTHCHECK is now functional, using the new healthcheck subcommand which polls the admin server's /health endpoint. This /health endpoint proxies to the extproc gRPC health check, returning HTTP 200 when SERVING. A new subcommand (`aigw healthcheck`) was needed as the image is distroless (has no curl etc). When aigw run starts Envoy, it polls for readiness using either the Envoy admin address (when configured in EnvoyProxy bootstrap) or by checking if the Gateway listener port accepts TCP connections. This ensures startup completes reliably with minimal Gateway configurations. Gateway validation now requires at least one listener to be configured. --------- Signed-off-by: Adrian Cole <adrian@tetrate.io>
Needed for Google import, we have multiple implementations of protobuf internally and need to be able to remap to the appropriate one.