Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Expose needed services on the control socket #1828
For swarm mode to function without exposing a TCP port, we need services
This is the first part of #1826, broken out of that PR as requested.
referenced this pull request
Dec 21, 2016
Current coverage is 54.58% (diff: 28.30%)
@@ master #1828 diff @@ ========================================== Files 102 102 Lines 17025 17094 +69 Methods 0 0 Messages 0 0 Branches 0 0 ========================================== + Hits 9286 9330 +44 - Misses 6599 6617 +18 - Partials 1140 1147 +7
This function generates Go code that wraps a client/server streaming RPC handler with a proxy. The proxy will just invoke the handler locally when called on the leader, but when it's called on a follower, it invokes the method remotely on the leader. The goal is to have certain handlers always run on the leader for consistency.
We want to tell the RPC handler that it was invoked locally. Formerly, it didn't need to know this explicitly. If it was invoked by a proxy that was forwarding the request, the proxy added metadata headers to the request, so the RPC handler knew where the request originated. And if the request happened to hit the leader without going through a level of proxying, we'd go by the TLS metadata that GRPC provides for us. But now we want these handlers to support requests that came over a unix socket, where TLS isn't in use. So we need to include some information with the node ID and so on.
We do this by injecting a custom context into the handler when it's called locally. With the simple handlers, this is trivial, because we can just call
You should see it for stream handlers, such as
Ah ok, thanks, yes I had only checked the simple handlers, and did not check further with log broker and dispatcher.
Ok, that makes sense, thanks for the explanation!