| Re: [jetty-dev] Allowing Jetty Proxy protocol support to fallback to regular HTTP |
> On Apr 2, 2016, at 3:59 AM, Simone Bordet <sbordet@xxxxxxxxxxx> wrote: > > Hi, > > On Sat, Apr 2, 2016 at 2:08 AM, Steven Schlansker > <stevenschlansker@xxxxxxxxx> wrote: >> Imagine you have a cluster of 10 load balancers and 10 Jetty servers. >> How do you atomically upgrade all 10 load balancers to send PROXY >> and 10 Jettys to receive PROXY, when any connection that is mismatched >> will be dropped? > > I don't understand. Updating your load balancer to send PROXY is a > once and then never again operation. > It would not be required if the load balancer was deployed initially with PROXY. Right, but we did not have that foresight. We already have a large existing deployment without PROXY and wish to upgrade. > >> We could set up an entirely parallel set of connectors and deployments. >> But the work to do this is large -- we have many datacenters across many >> continents, each of which has its own ELB -> Jetty input pipeline. >> Each one of these would need a temporary transition, where we first >> create a new connector, switch traffic over, and then remove the old >> connector. > > Yes. It's an operation that you do once and then you are done, and you > never do it again. We're estimating days to weeks of time necessary to do this cutover. It would save us a lot of time to not have to do this. > >> Wouldn't it be much easier if Jetty could autodetect? Then you can first >> upgrade Jetty, then enable it on ELB, and no need to do this dangerous >> rerouting of traffic at all :) > > What "dangerous" rerouting ? It's the simplest operation you can do on > a load balancer, to tell what is the backend port to direct traffic > to. Well, we also have to change firewall rules, monitoring checks... it sounds like a very easy operation but as soon as you sit down to do it and list out the steps the complexity grows quickly. And since this is the main ingress point for *all* our production traffic, any changes are by nature dangerous. > >> Do you have some specific reason this feature is not a good idea? >> It seems like it would be extremely handy. > > It may be handy in your case, but you found an equivalent easy > alternative solution that does not force Jetty to support a feature > that you are going to use only once *ever* per data center. > > Sorry if I seem harsh, but I don't see this feature being useful in > general, there is an easy alternative solution, and the feature is > something that you are going to use for only few minutes, and then > never again. Yes, we intend to use this to get the upgrade in, and then we can disable it forever. I think it's very useful to ease transitions like this. Since I'm mostly done with the code anyway, we'll use it to ease our transition and then go back to the main Jetty version -- I'm a little sad that you don't agree that there's value here but I certainly can understand defending the project against features you see as wrong. I'll close my PR presently. Sorry to spam the lists :) Best, Steven
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail