Re: [ANNOUNCE] haproxy-1.8.20
On Sun, May 05, 2019 at 10:59:29PM +0200, Vincent Bernat wrote: > ? 5 mai 2019 09:51 +02, Vincent Bernat : > > >> So I'd suggest to insist on having the up to date version (even 1.8.21 if > >> we have a reason to have this one released by then). In the worst case, > >> if this is rejected for whatever reason, it's better to leave a well known > >> version there and continue to encourage every user to switch to your up to > >> date PPA than making them believe their version contains the essential > >> fixes, which would be misleading. > > > > OK, I have just asked our release team if they would accept 1.8.20 as > > is. Let's see! > > They don't want to make an exception. So, Debian 10 will be with HAProxy > 1.8.19. OK, things have not changed much. Thanks for trying! Willy
Re: [ANNOUNCE] haproxy-1.8.20
❦ 5 mai 2019 09:51 +02, Vincent Bernat : >> So I'd suggest to insist on having the up to date version (even 1.8.21 if >> we have a reason to have this one released by then). In the worst case, >> if this is rejected for whatever reason, it's better to leave a well known >> version there and continue to encourage every user to switch to your up to >> date PPA than making them believe their version contains the essential >> fixes, which would be misleading. > > OK, I have just asked our release team if they would accept 1.8.20 as > is. Let's see! They don't want to make an exception. So, Debian 10 will be with HAProxy 1.8.19. -- Make it right before you make it faster. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-1.8.20
On Sun, May 05, 2019 at 09:51:11AM +0200, Vincent Bernat wrote: > ? 5 mai 2019 09:14 +02, Willy Tarreau : > > > So I'd suggest to insist on having the up to date version (even 1.8.21 if > > we have a reason to have this one released by then). In the worst case, > > if this is rejected for whatever reason, it's better to leave a well known > > version there and continue to encourage every user to switch to your up to > > date PPA than making them believe their version contains the essential > > fixes, which would be misleading. > > OK, I have just asked our release team if they would accept 1.8.20 as > is. Let's see! Thank you, Willy
Re: [ANNOUNCE] haproxy-1.8.20
❦ 5 mai 2019 09:14 +02, Willy Tarreau : > So I'd suggest to insist on having the up to date version (even 1.8.21 if > we have a reason to have this one released by then). In the worst case, > if this is rejected for whatever reason, it's better to leave a well known > version there and continue to encourage every user to switch to your up to > date PPA than making them believe their version contains the essential > fixes, which would be misleading. OK, I have just asked our release team if they would accept 1.8.20 as is. Let's see! -- Replace repetitive expressions by calls to a common function. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-1.8.20
Hi Vincent! On Sat, May 04, 2019 at 01:57:06PM +0200, Vincent Bernat wrote: > ? 29 avril 2019 11:04 +02, Christopher Faulet : > > > HAProxy 1.8.20 was released on 2019/04/25. It added 48 new commits > > after version 1.8.19. > > Hey! > > Debian Buster will soon be released (nobody knows exactly when, but we > are in full freeze since 2 months). It currently contains HAProxy > 1.8.19. I don't think it would be possible to push 1.8.20 as is. > > We can either keep 1.8.19 as is or select a few critical patches to > apply on it. For example, we could take the MAJOR patches: > > BUG/MAJOR: checks: segfault during tcpcheck_main > BUG/MAJOR: http_fetch: Get the channel depending on the keyword used > BUG/MAJOR: listener: Make sure the listener exist before using it. > BUG/MAJOR: spoe: Fix initialization of thread-dependent fields > BUG/MAJOR: stats: Fix how huge POST data are read from the channel > > And maybe: > > BUG/MEDIUM: listener: make sure the listener never accepts too many conns > > The more changes, the less likely the release team will accept the > change. Assuming we can only make one proposition (which is not true), > what would you (as upstream) try? 1.8.19, one bug, all major bugs, even > more bugs, or 1.8.20? As you know, I'm strongly opposed to cherry-picking only a small selection of bug fixes that are supposedly more important than other ones in certain environments while some users will only be affected by the ones not picked, because it means that you will deliberately ship known bugs to your users and put them at risk, which is really sad. For the vast majority of users, a deadlock in production caused by an unlikely bug is way more serious than a segfault which "cleanly" gets rid of the faulty process. In addition no single branch exists showing that only a random selection of patches works fine without the other ones, which means you can actually end up with debian-specific regressions caused exclusively by this bad practice. So I'd suggest to insist on having the up to date version (even 1.8.21 if we have a reason to have this one released by then). In the worst case, if this is rejected for whatever reason, it's better to leave a well known version there and continue to encourage every user to switch to your up to date PPA than making them believe their version contains the essential fixes, which would be misleading. Just my two cents, Willy
Re: [ANNOUNCE] haproxy-1.8.20
On Sat, May 4, 2019 at 1:58 PM Vincent Bernat wrote: > The more changes, the less likely the release team will accept the > change. Assuming we can only make one proposition (which is not true), > what would you (as upstream) try? 1.8.19, one bug, all major bugs, even > more bugs, or 1.8.20? Not being able to push 1.8.20 is a bit depressing as it will make potential bug reports a bit hard for developers to follow. But anyway, it will push more users to use your external repository and avoid the official one. -- William
Re: [ANNOUNCE] haproxy-1.8.20
Vincent, Am 04.05.19 um 13:57 schrieb Vincent Bernat: > The more changes, the less likely the release team will accept the > change. Assuming we can only make one proposition (which is not true), > what would you (as upstream) try? 1.8.19, one bug, all major bugs, even > more bugs, or 1.8.20? > While I'm not upstream I am a happy user of both HAProxy and Debian. I believe that this MEDIUM patch should be proposed as well. I believe the OpenSSL version included in Buster supports TLS 1.3. BUG/MEDIUM: ssl: ability to set TLS 1.3 ciphers using ssl-default-server-ciphersuites http://git.haproxy.org/?p=haproxy-1.8.git;a=commitdiff;h=a2919ca Best regards Tim Düsterhus
Re: [ANNOUNCE] haproxy-1.8.20
❦ 29 avril 2019 11:04 +02, Christopher Faulet : > HAProxy 1.8.20 was released on 2019/04/25. It added 48 new commits > after version 1.8.19. Hey! Debian Buster will soon be released (nobody knows exactly when, but we are in full freeze since 2 months). It currently contains HAProxy 1.8.19. I don't think it would be possible to push 1.8.20 as is. We can either keep 1.8.19 as is or select a few critical patches to apply on it. For example, we could take the MAJOR patches: BUG/MAJOR: checks: segfault during tcpcheck_main BUG/MAJOR: http_fetch: Get the channel depending on the keyword used BUG/MAJOR: listener: Make sure the listener exist before using it. BUG/MAJOR: spoe: Fix initialization of thread-dependent fields BUG/MAJOR: stats: Fix how huge POST data are read from the channel And maybe: BUG/MEDIUM: listener: make sure the listener never accepts too many conns The more changes, the less likely the release team will accept the change. Assuming we can only make one proposition (which is not true), what would you (as upstream) try? 1.8.19, one bug, all major bugs, even more bugs, or 1.8.20? -- Choose a data representation that makes the program simple. - The Elements of Programming Style (Kernighan & Plauger)
[ANNOUNCE] haproxy-1.8.20
Hi, HAProxy 1.8.20 was released on 2019/04/25. It added 48 new commits after version 1.8.19. The previous version was release few months ago. This one fixes several bugs, some rather important bugs: - A crash may happen upon exit if a thread closes a listener FD at the exact same moment another thread tries to accept() a pending connection on it. Issue reported and fixed by Richard Russo. - Willy significantly improved the listener's accept code by reducing the scope of the listener lock. He also made the code mode robust. At the end, thanks to this patch, the accept rate has doubled on a shared port between 8 threads, and multiplied by 4 the connection rate on a tcp-request connection reject rule. Moreover, Olivier implemented self-locked lists that can safely be manipulated with multiple threads without having to worry about concurrency issues. This allowed Willy to remove the lock on the listener queue thus fixing a possible AB/BA lock issue. - A bug affects the stats code from 1.5 and above when POST requests are supported (when admin mode is enabled) : some large POST requests may end up in a situation where the applet waits for more body and the analyser cannot send it because the buffer is considered full. This ultimately freezes the session. Now it is verified that the body length doesn't exceed what can fit in a request buffer. - The SPOE per-thread initialization would rely on a wrong agent pointer derivated from the last one known when parsing the configuration, making it fail if more than one agent is declared. Other bugs were also fixed on the SPOE, mainly on the way fragmented frames was handled internally. - An issue, fixed by Ricardo Nabinger Sanchez, affects checks and may occasionally cause crashes. - A very old bug on how HTTP sample fetches work was fixed. All HTTP sample fetches were buggy because the channel used was chosen depending on the sample direction and not on the keyword really used. The request channel was used when called during the request analysis and the response one was used when called during the response analysis, regardless the sample really called. It could cause a whole bunch of bugs, from undefined behavior because the data were extracted from the wrong buffer to crash of HAProxy. - Dragan Dosen fixed a possible segfault when HAProxy is built with the 51Degrees support but not configured to use it. Only builds that use Pattern algorithm were affected. - Pierre Cheynier fixed the TLS 1.3 cipher suites. Any attempt to put TLS 1.3 ciphers on servers failed with output 'unable to set TLS 1.3 cipher suites'. - A bug during the load of a map was fixed. Now when a map file is loaded, the default value is parsed only when it is present. This fixes segfaults at parsing time when no default value is provided. - Pattern IDs are now assigned after checking the config validity. It fixes a bug where some map identifiers were not assigned (appearing as -1 in show map). Thanks to Pavlos Parissis to report this bug. - A bug was fixed in the peers. Peer sessions were not always cleanly reset on release, resulting in a bad state for new sessions. - Build of HAProxy on AIX 5.1 was fixed. - Missing locks was added in set-map and add-acl HTTP rules. The rest is less important or doesn't have an immediately visible effect. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : http://www.haproxy.org/download/1.8/src/ Git repository : http://git.haproxy.org/git/haproxy-1.8.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-1.8.git Changelog: http://www.haproxy.org/download/1.8/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ --- Complete changelog : Christopher Faulet (9): BUG/MAJOR: spoe: Fix initialization of thread-dependent fields BUG/MAJOR: stats: Fix how huge POST data are read from the channel BUG/MEDIUM: spoe: Queue message only if no SPOE applet is attached to the stream BUG/MEDIUM: spoe: Return an error if nothing is encoded for fragmented messages BUG/MAJOR: http_fetch: Get the channel depending on the keyword used BUG/MEDIUM: thread/http: Add missing locks in set-map and add-acl HTTP rules BUG/MINOR: 51d: Get the request channel to call CHECK_HTTP_MESSAGE_FIRST() BUG/MINOR: da: Get the request channel to call CHECK_HTTP_MESSAGE_FIRST() BUG/MINOR: spoe: Don't systematically wakeup SPOE stream in the applet handler David Carlier (1): BUILD/MINOR: listener: Silent a few signedness warnings. Dragan Dosen (1): BUG/MEDIUM: 51d: fix possible segfault on deinit_51degrees() Emeric Br
