The gRFC has now been updated with the latest changes. On Thu, Feb 2, 2017 at 8:10 AM, Mark D. Roth <r...@google.com> wrote:
> 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. > -- 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/CAJgPXp6-hEABE2p1ydha_HtHcZ6G37RG_TzXz93OC9suGBq2Zw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
