Eric and I chatted about this at lunch yesterday. This message is intended mainly to document what we agreed upon and the logic we used to get there. (Eric, please correct anything I might get wrong here.)
My understanding of Eric's concern is that he believes that we will ultimately need to support the situation in case 1 where the client needs to talk to both internal and external servers, where only the latter should go through the proxy, and he was trying to drive us toward a solution that would address both that case and case 3 in a way that does not suffer from the drawback he pointed out for case 3 (i.e., needing to update the list of proxies known to the proxy mapper before you can add them to DNS). For case 1 with both internal and external servers, we agreed that we would need a hook right before the resolver is called to conditionally override the name being passed to the resolver. That way, we could insert logic that would ignore internal names but override external names to use the proxy name instead. Unfortunately, that approach doesn't really help address the problem Eric wanted to solve for case 3, because there we would want to use this hook to select the proxy only for the load balancers, not for the public name of the server. However, as per the proposed mechanism in gRFC A5 ( https://github.com/grpc/proposal/pull/10) for using SRV records to indicate load balancers, we would only pass the public name of the server to the resolver; the name for the load balancers will only be seen internally in the resolver, so it would not be visible to a hook right before the resolver is called. We could only think of two alternatives to this, both of which are unappealing: we could put the hook inside of the resolver itself, in which case every resolver implementation would need to support it, or we could change the resolver API such that we have to exit the resolver and then re-enter each time one name lookup spawns another one, which makes the API more complex. Neither of those seems worthwhile, given that we have a simpler solution to the case 1 situation that Eric was worried about and that the primary customer for case 3 (Julien) is fine with the currently proposed solution, despite the drawback that Eric has pointed out. So, we agreed to go ahead and add the hook for case 1 with both internal and external servers, but to leave the currently proposed solution for case 3 as-is. I've sent out a PR adding the new hook for case 1 to C-core ( https://github.com/grpc/grpc/pull/9557). I will update the gRFC and update this thread when that's done. On Wed, Feb 1, 2017 at 10:37 AM, Eric Anderson <ej...@google.com> wrote: > On Wed, Feb 1, 2017 at 10:16 AM, Mark D. Roth <r...@google.com> wrote: >> >> Do we know that there are cases where we'll need to support this? I >> don't doubt that there are cases where only connections to external servers >> should go through the proxy, but I wonder how many cases there are where >> users will need to use both internal and external servers with gRPC. >> > > So let me get this straight: we think there are users who can't use DNS > for external hostnames and need to use a proxy for external services. We > know this is most likely in corporate and server environments (for > security). But we wouldn't support those user's jumping further on the gRPC > bandwagon because it either wouldn't work or performance and overhead would > be poor. > > Or conversely: if you are using gRPC for your own communication, you > cannot use gRPC to communicate with "the cloud", except if you accept a > performance drop for the existing traffic and increased overhead. > > If/when we do support this, do we have some idea how this would be >> configured? Is there some standard way of configuring which server names >> are internal vs. which are external, or would it be custom code for each >> environment? >> > > Probably custom code. > -- Mark D. Roth <r...@google.com> Software Engineer Google, Inc. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAJgPXp5o-NfdiZyn-79yEjYm%2BKkSRvhXEoS6ZSZRdutYFjsMpQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
