stable-bot: Bugfixes waiting for a release 2.1 (24), 2.0 (1)
Hi,
This is a friendly bot that watches fixes pending for the next haproxy-stable
release! One such e-mail is sent periodically once patches are waiting in the
last maintenance branch, and an ideal release date is computed based on the
severity of these fixes and their merge date. Responses to this mail must be
sent to the mailing list.
Last release 2.1.4 was issued on 2020-04-02. There are currently 24 patches in
the queue cut down this way:
- 10 MEDIUM, first one merged on 2020-05-01
- 14 MINOR, first one merged on 2020-04-02
Thus the computed ideal release date for 2.1.5 would be 2020-04-30, which was
one week ago.
Last release 2.0.14 was issued on 2020-04-02. There are currently 1 patches in
the queue cut down this way:
- 1 MINOR, first one merged on 2020-04-02
Thus the computed ideal release date for 2.0.15 would be 2020-04-30, which was
one week ago.
The current list of patches in the queue is:
- 2.1 - MEDIUM : shctx: really check the lock's value
while waiting
- 2.1 - MEDIUM : capture: capture.{req,res}.* crash
without a stream
- 2.1 - MEDIUM : http-ana: Handle NTLM messages
correctly.
- 2.1 - MEDIUM : listener: mark the thread as not stuck
inside the loop
- 2.1 - MEDIUM : http: the "unique-id" sample fetch
could crash without a steeam
- 2.1 - MEDIUM : server/checks: Init server check
during config validity check
- 2.1 - MEDIUM : http: the "http_first_req" sample
fetch could crash without a steeam
- 2.1 - MEDIUM : sample: make the CPU and latency
sample fetches check for a stream
- 2.1 - MEDIUM : shctx: bound the number of loops that
can happen around the lock
- 2.1 - MEDIUM : capture: capture-req/capture-res
converters crash without a stream
- 2.1 - MINOR : connection: always send address-less
LOCAL PROXY connections
- 2.1 - MINOR : ssl: default settings for ssl server
options are not used
- 2.1 - MINOR : mux-fcgi: Be sure to have a connection
as session's origin to use it
- 2.1 - MINOR : tools: fix the i386 version of the
div64_32 function
- 2.1 - MINOR : obj_type: Handle stream object in
obj_base_ptr() function
- 2.1 - MINOR : checks: Respect the no-check-ssl option
- 2.1 - MINOR : debug: properly use long long instead
of long for the thread ID
- 2.1 - MINOR : peers: Incomplete peers sections
should be validated.
- 2.1 - MINOR : checks: chained expect will not
properly wait for enough data
- 2.1 - MINOR : http: make url_decode() optionally
convert '+' to SP
- 2.1 - MINOR : ssl: memleak of the struct
cert_key_and_chain
- 2.1 - MINOR : check: Update server address and port
to execute an external check
- 2.1 - MINOR : ssl/cli: memory leak in 'set ssl cert'
- 2.0, 2.1 - MINOR : protocol_buffer: Wrong maximum
shifting.
--
The haproxy stable-bot is freely provided by HAProxy Technologies to help
improve the quality of each HAProxy release. If you have any issue with these
emails or if you want to suggest some improvements, please post them on the
list so that the solutions suiting the most users can be found.
Re: [ANNOUNCE] haproxy-2.2-dev7
Hi William, On Tue, May 05, 2020 at 11:57:47PM +0200, William Dauchy wrote: > > Christopher Faulet (136): > > MAJOR: checks: Implement HTTP check using tcp-check rules > > What is funny after this commit is that we wrongly relied on a config > which was written that way: > http-check expect status 200 string passing > instead of: > http-check expect status 200 > http-check expect string passing > > I first thought about a bad regression even though the documentation > does not allow it, but `string passing` was never evaluated, and so > silently ignored; now things are enforced which is better for us to > see those long standing mistakes ;) Ah interesting. We have many checks for unused extraneous parameters, but it's possible that a few still managed to pass through. It might be good if we can adjust this one to at least emit a warning in older branches. Thanks for the feedback! Willy
Re: [ANNOUNCE] haproxy-2.2-dev7
Hello, Thank you for this release update! On Tue, May 5, 2020 at 11:46 PM Willy Tarreau wrote: > HAProxy 2.2-dev7 was released on 2020/05/05. It added 205 new commits > after version 2.2-dev6. > > The most visible changes in this version is the rework of the health checks > that was started by Gaėtan and completed by Christopher. I'll certainly say > a number of stupidities about all this so I won't enter into details, but the > main points to be aware of is that the health checks which for 18 years have > been the ugliest part of the internals have now become smart. They are now > all internally implemented on top of tcp-check rules, and that these ones > were improved to satisfy the new requirements. For now all this new stuff is > not yet fully exploited beyond what is needed for the checks but we can hope > a lot of new cool stuff in a near future. > > In addition, HTTP checks now run over HTX and employ the muxes so they can > now run over HTTP/1 and HTTP/2, and can separately set headers and body. > All the elements may be extracted and processed for advanced checks. You > should refer to the documentation to figure all the details. Please beware > that the check configuration rules are subject to change a little bit before > the release but the main principle is already here. > Christopher Faulet (136): > MAJOR: checks: Implement HTTP check using tcp-check rules What is funny after this commit is that we wrongly relied on a config which was written that way: http-check expect status 200 string passing instead of: http-check expect status 200 http-check expect string passing I first thought about a bad regression even though the documentation does not allow it, but `string passing` was never evaluated, and so silently ignored; now things are enforced which is better for us to see those long standing mistakes ;) Thanks Christopher! -- William
[ANNOUNCE] haproxy-2.2-dev7
Hi,
HAProxy 2.2-dev7 was released on 2020/05/05. It added 205 new commits
after version 2.2-dev6.
The most visible changes in this version is the rework of the health checks
that was started by Gaëtan and completed by Christopher. I'll certainly say
a number of stupidities about all this so I won't enter into details, but the
main points to be aware of is that the health checks which for 18 years have
been the ugliest part of the internals have now become smart. They are now
all internally implemented on top of tcp-check rules, and that these ones
were improved to satisfy the new requirements. For now all this new stuff is
not yet fully exploited beyond what is needed for the checks but we can hope
a lot of new cool stuff in a near future.
In addition, HTTP checks now run over HTX and employ the muxes so they can
now run over HTTP/1 and HTTP/2, and can separately set headers and body.
All the elements may be extracted and processed for advanced checks. You
should refer to the documentation to figure all the details. Please beware
that the check configuration rules are subject to change a little bit before
the release but the main principle is already here.
Just before releasing I noticed one minor regtest failure on openssl 1.0.2
only, that I bisected to commit df38f88 ("MINOR: checks: Improve log message
of tcp-checks on success") (which sadly, doesn't have any commit message).
This failure is only about the logged message on check failure. I don't see
any obvious reason why this commit would only affect openssl 1.0.2 so I
guess the issue is somewhere else, and likely not much important.
Aside this there were a number of code cleanups, regtest additions and doc
updates. Among the other pending things I'm aware of is the support for
syslog over TCP and that should be all.
My personal feeling is that the rate of changes is still a bit high this
late in the cycle and that the level of issues remains high as well, and
I would appreciate it when it starts to calm down. I wouldn't be surprized
if we'd release in early June rather than end of May. But there's no rush
and that doesn't make a huge difference, provided it allows us to have an
excellent 2.2.
If you have painful checks in your configs, or some unusual ones, your
feedback will be welcome. If you're facing limitations with your HTTP
checks, it might be the right moment to give this one a try.
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/2.2/src/
Git repository : http://git.haproxy.org/git/haproxy.git/
Git Web browsing : http://git.haproxy.org/?p=haproxy.git
Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG
Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/
Willy
---
Complete changelog :
Baptiste Assmann (3):
MINOR: ist: add istadv() function
MINOR: ist: add istissame() function
MINOR: istbuf: add ist2buf() function
Christopher Faulet (136):
BUG/MINOR: http-ana: Throw a 500 error if after-response ruleset fails on
errors
BUG/MINOR: check: Update server address and port to execute an external
check
MINOR: mini-clist: Add functions to iterate backward on a list
MINOR: checks: Add a way to send custom headers and payload during http
chekcs
BUG/MINOR: checks: Respect the no-check-ssl option
BUG/MEDIUM: server/checks: Init server check during config validity check
CLEANUP: checks: Don't export anymore init_check and
srv_check_healthcheck_port
BUG/MINOR: checks: Forbid tcp-check lines in default section as documented
MINOR: checks: Stop xform buffers to null-terminated string for tcp-check
rules
MINOR: checks: Simplify functions to get step id and comment
MEDIUM: proxy/checks: Register a keyword to parse tcp-check rules
MEDIUM: checks: Add implicit tcp-check connect rule
MAJOR: checks: Refactor and simplify the tcp-check loop
MINOR: checks: Add the sni option for tcp-check connect rules
MINOR: checks: Add the via-socks4 option for tcp-check connect rules
MINOR: checks: Add the alpn option for tcp-check connect rules
MINOR: ssl: Export a generic function to parse an alpn string
MINOR: checks: Add the default option for tcp-check connect rules
MINOR: checks: Add the addr option for tcp-check connect rule
MEDIUM: checks: Support expression to set the port
MEDIUM: checks: Support log-format strings for tcp-check send rules
MINOR: log: Don't depends on a stream to process samples in log-format
string
MINOR: log: Don't systematically set LW_REQ when a sample expr is added
MEDIUM: checks: Add a shared list of tcp-check rules
MINOR: sample: add htonl converter
MINOR: sample: add cut_crlf
Distance Learning Package: Bid Writing
NFP WORKSHOPS 18 Blake Street, York YO1 8QG Affordable Training Courses for Charities, Schools & Public Sector Organisations This email has been sent to haproxy@formilux.org CLICK TO UNSUBSCRIBE FROM LIST Alternatively send a blank e-mail to unsubscr...@nfpmail1902.co.uk quoting haproxy@formilux.org in the subject line. Unsubscribe requests will take effect within seven days. Bid Writing: Distance Learning Package Learn at your home or office. No need to travel anywhere. Delivered by e-mail. The package includes all the topics from our popular Bid Writing: The Basics and Bid Writing: Advanced live workshops plus eight sample funding bids. Once you have covered all the materials you can submit up to five questions by email. TOPICS COVERED Do you know the most common reasons for rejection? Are you gathering the right evidence? Are you making the right arguments? Are you using the right terminology? Are your numbers right? Are you learning from rejections? Are you assembling the right documents? Do you know how to create a clear and concise standard funding bid? Are you communicating with people or just excluding them? Do you know your own organisation well enough? Are you thinking through your projects carefully enough? Do you know enough about your competitors? Are you answering the questions funders will ask themselves about your application? Are you submitting applications correctly? Are you applying to the right trusts? Are you applying to enough trusts? Are you asking for the right amount of money? Are you applying in the right ways? Are your projects the most fundable projects? Are you carrying out trust fundraising in a professional way? Are you delegating enough work? Are you highly productive or just very busy? Are you looking for trusts in all the right places? How do you compare with your competitors for funding? Is the rest of your fundraising hampering your bids to trusts? Do you understand what trusts are ideally looking for? TRAINEES Staff members, volunteers, trustees or board members of charities, schools or public sector organisations who intend to submit grant funding applications to charitable grant making trusts and foundations. People who provide advice to these organisations may also order. FORMAT The distance learning package consists of a 201 page text document in PDF format plus 8 real successful bids totalling 239 pages in PDF format. There is no audio or video content. This is not an online course. TIME COMMITMENT Trainees should expect to spend around eight hours reading through all the materials, preparing their "to do" list for the months ahead, writing or revising their standard funding bid, submitting questions by email and processing responses. TERMS Training materials are for use only by the trainee named on the invoice. Training materials may not be copied, circulated or published. ORDER YOUR PACKAGE NOW The cost of the Bid Writing: Distance Learning Package is £190 per trainee. To order please email ord...@nfpmail1902.co.uk with 1) The name of the trainee. 2) The email address to send the materials to. 3) The name of your organisation. 4) The postal address of your organisation. 5) A purchase order number if required. We will send you an invoice within 24 hours containing BACS electronic payment details. Once we receive payment the materials will be emailed to the specifed email address within 24 hours. Please check your spam folder to ensure you receive everything. QUESTIONS If you have a question please e-mail questi...@nfpmail1902.co.uk You will usually receive a response within 24 hours. We are unable to accept questions by phone. FEEDBACK FROM PAST ATTENDEES AT OUR LIVE WORKSHOPS I must say I was really impressed with the course and the content. My knowledge and confidence has increased hugely. I got a lot from your course and a lot of pointers! I can say after years of fundraising I learnt so much from your bid writing course. It was a very informative day and for someone who has not written bids before I am definitely more confident to get involved with them. I found the workshops very helpful. It is a whole new area for me but the information you imparted has given me a lot of confidence with the direction I need to take and for that I am very grateful. I found the day very informative and it gave me confidence to take on this aspect of work that I had been apprehensive of. I enjoyed the session and found it valuable. So much relevant, practical information all passed on in a way which I was able to follow. All greatly enhanced by your sense of humour. It was a useful course and your examples real or otherwise helped to make it practical. Many thanks. The morning just flew by - always a good sign! I enjoyed the course and learnt a lot. I will begin putting this into practice.
Re: Question about connection settings proto fcgi check maxconn 9 minconn 5 maxqueue 0
Christopher, Aleks, Am 04.05.20 um 11:28 schrieb Christopher Faulet: > Le 03/05/2020 à 09:52, Aleksandar Lazic a écrit : >> >> My php-fpm have the following settings. >> >> ``` >> pm = dynamic >> pm.max_children = 10 >> pm.min_spare_servers = 4 >> pm.start_servers = 5 >> pm.max_spare_servers = 6 >> pm.max_requests = 500 >> ``` >> > [...] > > Hi Aleks, > > I've made some tests on my side and the fork politic of php-fpm seems to > be a bit strange because with the same config and the check disabled, > I've the same warning and 10 php-fpm children with only 3 clients. When > I checked the opened connections, I only have 4 connections. So there is > no reason to have 10 children. > It does not looks too off to me given Aleks' configuration: PHP starts off with 5 worker processes (idle). If at least 6 requests come in at the same time then PHP will reach 10 worker processes, because PHP is configured to keep 4 idle processes at all times. A 7th request would violate the minimum number of idle processes. Now if the number of concurrent requests goes down to 4 you will still see the 10 processes, because PHP is allowed to keep 6 idle processes around. Best regards Tim Düsterhus
Re: [PATCH] MINOR: lua: allow changing port with set_addr
Merged. Thanks ! -- Christopher
