*From: *Jinn Ko <hapr...@mx.ixido.net> *Sent: * 2013-09-24 10:22:49 E *To: *haproxy@formilux.org *Subject: *Re: AW: GA Release of 1.5
> Hi, > > It's good to get a better idea of what's needed to see a GA release of > 1.5. We've been keenly awaiting the GA release, and I certainly > understand the need to ensure the high performance that we've all come > to expect of HAProxy. > > In this case, however, I would propose the features are significant > enough to stabilize what's there and manage expectations. > > An important reason to release the SSL feature set as is could be for > the potential to release timely security fixes when vulnerabilities or > exploits are discovered. > > With the knowledge that server-side keep-alives aren't currently > supported together with SSL we could plan our production deployment to > take this into account until a future release does support the > combination. Documentation could very well reflect these limitations > and serve to manage users expectations. I cannot disagree with this argument more. You're requesting that incomplete software be released because you can work around the deficiencies in it. People expect that when new versions of software are released, that the software is complete and functional. > > On 2013-09-23 11:56, Lukas Tribus wrote: > > Hi! > > > >> If you feel SSL support being stable I would really like to see > >> a release. This is THE main reason for 1.5. > > > I understand your point, but server side keep alives for example > > are important when you run SSL on the backend side, otherwise you > > end up establishing a new SSL session for each and every HTTP > > request. > > > I doubt that would scale very well. > > > In our case we're deploying a single service and are using the 1.5 > branch primarily to support websockets over SSL, something that was > fiddly, if not difficult, prior to having SSL support within HAProxy. > > One of the main reasons for the difficulties with websocket over SSL > is the treatment of the Connection header, which the alternative SSL > terminator, nginx, is in fact observing the correct behaviour defined > in the relevant RFC. Alternative means of terminating SSL are also > fiddly and we haven't tested them with websockets. > > The good news is haproxy-1.5-dev has been working great for the past > few months that we've been using it, albeit only in pre-production and > performance testing environments for now. The performance aspect > hasn't been a bottleneck for us so far, so is a minor concern. > > > >> Please don't put the burdon of patching relevant fixes to the > >> current users. (It's not patching, but filtering which patches > >> are relevant). > > > That was just a proposal; whether its achievable or not depends on > > you. > > > Unfortunately we don't have the resources to maintain a branch to > which we could backport relevant fixes, not to mention the overhead of > managing any security related fixes. But by requesting that 1.5 be released, you're essentially asking the people maintaining HAProxy to do the same thing. While you might argue that maintaining haproxy is their duty, they are doing that duty by releasing 1.5 when they feel it is ready. > > > Now if you are a multi national, multi billion dollar company > > implementing haproxy in a commercial product, you can probably > > justify the effort (or the risk of a unstable component in your > > product - in the end this is just a numbers game for a big > > company). > > > If you are a haproxy end-user, I don't see why using a current > > snapshot of the code would hurt (*if you have the time to deploy > > an OSS solution*). Sure, you shoud not blindly upgrade to more > > recent code without extensively testing it first, but that may be a > > good thing to do with stable releases as well. > > We'd certainly fall into this category, however while we're a start-up > (with no funding), this isn't a great situation to be in. The concern > for potential security issues is also valid. > > > > If you don't have the time and need those bleeding edge features > > today, then you should probably stick to a commercial solution, > > like those from exceliance.fr or loadbalancer.org. > > I'm not sure if either of these offer websocket+SSL support, but > certainly worth investigating. > > > > I don't think releasing new stable branches every 6 months is a > > good thing, because in the end, you need long term support for > > this deployments. You don't want to upgrade from one stable major > > release to another every 12 months because of their deprecation, > > right? > > While the release cycles are a topic in themselves, supporting > relatively major developments such as SSL and websocket support is > important for the community. I'm also going to have to voice opinion against rapid release cycles. One significant result is that distributions end up using old unsupported versions, and users of that distro being unable to get help from the community, and as a result having to roll their own packages. Haproxy has been in existence for years without SSL support. Just because the development version of the software has some big feature isn't a valid argument that the development branch should be released. There are lots of other big features in the development branch, we can't have a release for every one of them. > > Can't have all the features in stable branches right away and then > > expect those branches to be supported for years to come, imho. > > Point taken and certainly an important consideration. > > Best regards, > Jinn Personally there are still several things that have been talked about for 1.5 that I am still hoping to see. So I for one hope that 1.5 is not released until it is finished. -Patrick
signature.asc
Description: OpenPGP digital signature
