On Fri, Jan 27, 2017 at 9:16 AM, Eric Anderson <ej...@google.com> wrote:
> On Thu, Jan 26, 2017 at 12:46 PM, Mark D. Roth <r...@google.com> wrote: > >> I've attempted to modify the language in the doc to make it clear that >> the intent is for outbound traffic to go through the proxy, but that this >> is often implemented by having *all* traffic go through the proxy. >> Please let me know if this addresses your concern. >> > > The modification looks great. > > Let me try to make sure I'm understanding you right here. It sounds like >> you're suggesting that instead of giving the proxy mapper the ability to >> control whether the CONNECT argument is a hostname or an IP address, we >> instead always assume that we should use the IP address in the CONNECT >> request whenever use of a proxy is indicated by a proxy mapper. In other >> words, we would determine the CONNECT argument based on where the use of >> the proxy was triggered (i.e., from the client channel code vs. from a >> proxy mapper) instead of having the proxy mapper explicitly control it. Is >> that right? >> > > Yes. And that seems to agree with how the different proxy choosing logic > will work; the first primarily consumes hostnames and returns proxy > hostnames (which is http_proxy in C) and the second one primarily consumes > IPs and returns proxy IPs. > I don't think that's actually entirely correct. The first case doesn't consume anything; it unconditionally sets the hostname to be resolved. And the second case can consume either the hostname or the IP. This is more philosophical than practical, but I think the distinction between the two cases is not really about what they consume or provide; it's actually about whether we can do name resolution directly or whether we need to rely on the proxy to do it for us. > > But that philosophical debate aside, I think that we should focus on case >> 3, because that's a concrete case that we do want to support. So far, at >> least, I have not heard a workable proposal that does not require the proxy >> mapper to control the CONNECT argument (although I'm certainly still open >> to new proposals). >> > > I've provided two proposals. Neither of which seem debunked as of yet. I > could totally agree they may be worse than what you are proposing, but the > discussion hasn't gotten to that point. The mentioned security issue of the > first proposal seemed to ignore the fact that a reverse proxy could be used > to "protect" the LB, in an identical fashion to any forward proxy. > I don't quite understand the proposed reverse proxy approach. Can you explain how that would work in more detail? > > I can think of one possible middle-ground approach here, which is that >> instead of having the proxy mapper specify the CONNECT argument string, it >> just indicates whether the argument should be the original hostname or the >> IP address returned by the resolver. That way, it can control what it >> needs to but can't completely override the results of the resolver. I'm >> not super enthusiastic about this approach, since it seems like it actually >> makes the interface a bit harder to understand, but I'm curious what you >> think of it. >> > > Meh. It still requires coupling the proxy mapper with other parts of the > system. And I'm not convinced that coupling works. It does make me feel a > bit better about the predictability of the system though. And that is > important to have an orthogonal system which helps as you try to add more > features/refactor. > If this doesn't actually address your concerns, then let's not consider it, since I'm not very enthusiastic about it either. > > But you didn't address my concerns that the mapping code doesn't actually >>> know the proxy addresses, unless it never changes. But if it never changes >>> then you have stability issues. >>> >> >> The whole point of the proxy mapper is to provide a hook for the logic >> that knows what proxy address to use. It has to have some source of that >> data, whether it be hard-coded or read from a file or something else >> entirely. >> > > It has to provide *an* address. It doesn't have to have global knowledge > of *all possible* addresses, which are even coming from a *separate *system. > Will the two different systems be updated in concert, which may need to be > simultaneously/atomically? Seems unlikely, in part because it is > non-obvious they need to be. But let's say they do. > Then we also have to deal with configuration changes during the time the > name resolver runs and the proxy mapper runs. This is asking for bugs. The > design is brittle and feels like it requires different parts of the system > to be tied together with duct tape. > I agree that case 3 requires different parts of the system to be coordinated. For example, assuming that your proxy mapper implementation is getting the list of proxy addresses from a local file, you would need to first push an updated list that contains the new proxy address to all clients. Then, once all clients have been updated, you can add the new proxy to DNS. I agree that this is cumbersome, but I think it's an inherent problem with case 3, because you need *some* way to configure the clients. I think the only way to completely avoid this would be to go with a gRPC-level proxy, as described in the "Rationale" section of the doc. > > If you assume "one proxy" which has "one static IP" and everything is > hard-coded, then the design is fine. But that seems unlikely to describe a > productionized system. And that's why I would feel forced to use the "magic > IP" that it seems you have previously rejected. > There are a couple of reasons that I don't like the "magic IP" approach. First, it requires writing a custom resolver in addition to a custom proxy mapper, when it really should be fully possible to use the existing resolver. And second, I'm not a big fan of "sentinel" values, since it's often hard to find a value that will never be used in real life. -- 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_gvy3XEs4_X__NnKFUTXJXDaMuGDyVJdwV32qES-6nA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
