[Pkg-haproxy-maintainers] Recommended strategy for running 1.5 in production

[Willy Tarreau]

Hi Apollon,

On Wed, Apr 16, 2014 at 09:22:56PM +0300, Apollon Oikonomopoulos wrote:
> (Cc'ing the Debian maintainers as well)
> 
> Hi all,
> 
> On 19:28 Wed 16 Apr     , Willy Tarreau wrote:
> > On Wed, Apr 16, 2014 at 07:14:31PM +0300, pablo platt wrote:
> > > An official Ubuntu dev repo will also make testing easier.
> > > It's much easier to use a apt-get than building from source and figuring
> > > out command line options.
> 
> Actually Vincent Bernat maintains a PPA with rebuilds of our Debian 
> packages from experimental, which should be handy for Ubuntu users:
> 
>   https://launchpad.net/~vbernat/+archive/haproxy-1.5
> 
> > 
> > I think we're getting close to a release so we should not harrass distro
> > maintainers with that *now* (but we could have done years ago). That
> > reminds me that I tend not to always realize how much time slips between
> > versions, and to forget that sometimes a previous version has some 
> > bugs.
> > 
> > What I'd expect from our users is to sometimes complain loudly and insist
> > for having a new dev release when the latest snapshot has become more
> > reliable than the last dev release if that makes their lifes easier. A
> > new version doesn't cost much (1 hour to read the changelog, write a
> > human-friendly summary in an announce e-mail and update the site).
> 
> With my Debian hat on, I'd like to "complain" a bit about 1.5. Of course 
> we appreciate your dedication to making HAProxy rock-solid and 
> feature-complete and at this point as a user 1.5 has been pretty stable 
> for me (and the new features are definitely worth the wait).
> 
> However, as Debian maintainers we probably will not replace 1.4 with 1.5 
> in our main track (unstable -> testing -> wheezy-backports) until 
> 1.5-final is out; we would like to make sure that we will end up with a 
> proper 1.5 release in Debian Jessie (and not with a development snapshot 
> at any rate) that both, upstream and ourselves will be willing to 
> support.
> 
> Unfortunately, this means that 1.5 currently gets less user exposure (at 
> least via Debian and Ubuntu), potentially slowing down the stabilization 
> process. So please, leave some features aside for 1.6 ;-)

I know and the goal clearly is not to add new features to 1.5, but to fix
what still remains to be fixed before the release otherwise we'd have to
risk breaking some supposed stable setups later when backporting fixes :

  - fix the HTTP body parser to get rid of the mess it is when mixing
    redispatch with check_post, not to mention compression.

  - fix the compression to re-enable compression of chunked-encoded
    responses

  - adapt the check agent to the final API we agreed on the list a few
    weeks ago

  - fix the bind-process lameness.

I'm still working on point #1 and making progress (I was even writing some
architecture doc on it to engrave the changes so that we avoid breaking
that soon again). #2 should follow shortly after that. #3 is apparently
easy (I had a beginning of patch 2 months ago to start on it) but we noticed
that the check agent touches many intimate parts of the checks and I expect
a few surprizes again. However, I don't care much about minor bugs for the
final release provided that the architecture is ready to accept fixes
without putting users at risk. For #4, I think we can keep the users in a
safe working area to prepare them for upgrades by simply emitting a few
warnings in the configs leading to a corner case.

I really think we're on the right track, we must just not stop efforts.
And the fact that we get lots of bug reports is a good sign as well!

Cheers,
Willy