Re: HAProxy 1.6 (was: [ANNOUNCE] haproxy-2.4-dev4)
Hi Tim, On Mon, Dec 21, 2020 at 07:08:45PM +0100, Tim Düsterhus wrote: > Looking at haproxy.org I am seeing that the end of life for HAProxy 1.6 > is Q4-2020. Q4 is almost over. Is this on your radar? It probably makes > sense to: > > - do a final 1.6 release, and > - at the same time move 1.8 to "critical fixes" only. Yes that was indeed the plan. As every year I just forget about it, so thanks for the reminder :-) Willy
Re: [PATCH] add 3 popular "contrib" tools to github actions builds
пн, 21 дек. 2020 г. в 22:59, Tim Düsterhus : > Ilya, > > Am 21.12.20 um 13:41 schrieb Илья Шипицин: > > this will hopefully prevent regressions on halog. > > > > I disagree with putting these into the VTest workflow. They do not > depend on VTest and they do not depend on the build flags. > > Can you create a dedicated YML file for these, similar to the compliance > and codespell ones? > please ignore this patch, I will send new one. > > Best regards > Tim Düsterhus >
[PATCH] BUG/???: mux_h2: Add missing braces
Willy,
please fill in the severity yourself, because I don't know what effects this
bug causes.
Check the issue for details:
https://github.com/haproxy/haproxy/issues/1015
Best regards
Tim Düsterhus
Apply with `git am --scissors` to automatically cut the commit message.
-- >8 --
This is a regression in 7838a79bac6ff2d81c9ff681d80644489511fa3f. The issue was
found using -Wmisleading-indentation. This patch fixes GitHub issue #1015.
This patch should be backported to 2.1+, the commit was first tagged in
v2.1-dev2.
---
src/mux_h2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mux_h2.c b/src/mux_h2.c
index c712eb3c2..e4fb6c3f2 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -6160,9 +6160,10 @@ static size_t h2_snd_buf(struct conn_stream *cs, struct
buffer *buf, size_t coun
htx_to_buf(htx, buf);
if (total > 0) {
- if (!(h2s->h2c->wait_event.events & SUB_RETRY_SEND))
+ if (!(h2s->h2c->wait_event.events & SUB_RETRY_SEND)) {
TRACE_DEVEL("data queued, waking up h2c sender",
H2_EV_H2S_SEND|H2_EV_H2C_SEND, h2s->h2c->conn, h2s);
tasklet_wakeup(h2s->h2c->wait_event.tasklet);
+ }
}
/* If we're waiting for flow control, and we got a shutr on the
--
2.29.0
HAProxy 1.6 (was: [ANNOUNCE] haproxy-2.4-dev4)
Willy, Am 21.12.20 um 12:22 schrieb Willy Tarreau: > HAProxy 2.4-dev4 was released on 2020/12/21. It added 33 new commits > after version 2.4-dev3. > > In this traditionally calm period, there aren't that many changes, except > a lot of bug fixes. Actually 3 bugs in dev3 managed to cause crashes on > haproxy.org, this hadn't happened in a very long time. And I'm glad we're > running development versions there because all 3 could be quickly spotted > and fixed :-) > Looking at haproxy.org I am seeing that the end of life for HAProxy 1.6 is Q4-2020. Q4 is almost over. Is this on your radar? It probably makes sense to: - do a final 1.6 release, and - at the same time move 1.8 to "critical fixes" only. Best regards Tim Düsterhus
Re: [ANNOUNCE] haproxy-2.4-dev4
Willy, Am 21.12.20 um 12:22 schrieb Willy Tarreau: > Just my two cents, I'm interested in anyone's opinion or suggestion here. Your proposal sounds good to me. Best regards Tim Düsterhus
Re: [PATCH] add 3 popular "contrib" tools to github actions builds
Ilya, Am 21.12.20 um 13:41 schrieb Илья Шипицин: > this will hopefully prevent regressions on halog. > I disagree with putting these into the VTest workflow. They do not depend on VTest and they do not depend on the build flags. Can you create a dedicated YML file for these, similar to the compliance and codespell ones? Best regards Tim Düsterhus
Bid Writing, Major Donors and Volunteering Workshops
NFP WORKSHOPS 18 Blake Street, York YO1 8QG 01133 280988 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...@nfpmail2001.co.uk quoting haproxy@formilux.org in the subject line. Unsubscribe requests will take effect within seven days. Bid Writing: The Basics Online via ZOOM COST £95 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? PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits 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 are also welcome. Bid Writing: Advanced Online via ZOOM COST £95 TOPICS COVERED 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? PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits 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 are also welcome. Dates & Booking Links BID WRITING: THE BASICS Mon 21 Dec 2020 10.00 to 12.30Booking Link Mon 11 Jan 2020 10.00 to 12.30Booking Link Mon 25 Jan 2020 10.00 to 12.30Booking Link Mon 08 Feb 2020 10.00 to 12.30Booking Link Mon 22 Feb 2020 10.00 to 12.30Booking Link BID WRITING: ADVANCED Tue 22 Dec 2020 10.00 to 12.30Booking Link Tue 12 Jan 2020 10.00 to 12.30Booking Link Tue 26 Jan 2020 10.00 to 12.30Booking Link Tue 09 Feb 2020 10.00 to 12.30Booking Link Tue 23 Feb 2020 10.00 to 12.30Booking Link Recruiting and Managing Volunteers Online via ZOOM COST £195 TOPICS COVERED Where do you find volunteers? How do you find the right volunteers? How do you attract volunteers? How do you run volunteer recruitment events? How do you interview volunteers? How do you train volunteers? How do you motivate volunteers? How do you involve volunteers? How do you recognise volunteer? How do you recognise problems with volunteers? How do you learn from volunteer problems? How do you retain volunteers? How do you manage volunteers? What about volunteers and your own staff? What about younger, older and employee volunteers? PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits or public sector organisations who intend to recruit volunteers into their organisation and then manage those volunteers. People who provide advice to these organisations are also welcome. Dates & Booking Links RECRUITING AND MANAGING VOLUNTEERS Wed 13 Jan 2021 10.00 to 16.00Booking Link Wed 10 Mar 2021 10.00 to 16.00Booking Link Major Donor Fundraising Online via ZOOM COST £95 TOPICS COVERED Major Donor Characteristics, Motivations and Requirements. Researching and Screening Major Donors. Encouraging, Involving and Retaining Major Donors. Building Relationships with Major Donors. Major Donor Events and Activities. Setting Up Major Donor Clubs.Asking For Major Gifts. Looking After and Reporting Back to Major Donors. Delivering on Major Donor Expectations. Showing Your Appreciation to Major Donors. Fundraising Budgets and Committees. PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits or public sector organisations who intend to carry out Major Donor Fundraising. People who provide advice to these organisations are also welcome. Dates & Booking Links MAJOR DONOR FUNDRAISING Wed 10 Feb 2021 10.00 to 12.30Booking Link Wed 14 Apr 2021 10.00 to 12.30Booking Link FEEDBACK FROM PAST ATTENDEES AT LIVE WORKSHOPS I must say I was really impressed with the
[PATCH] add 3 popular "contrib" tools to github actions builds
Hello,
this will hopefully prevent regressions on halog.
Ilya
From 57696674aef9431a01db6405cdba8b164162e2b9 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Mon, 21 Dec 2020 17:35:37 +0500
Subject: [PATCH] CI: github actions: build several popular "contrib" tools
this adds "halog", "flags" and "poll" builds. builds are done in
separate steps for better failure identification
---
.github/workflows/vtest.yml | 9 +
1 file changed, 9 insertions(+)
diff --git a/.github/workflows/vtest.yml b/.github/workflows/vtest.yml
index 6d42db8ff..ff290e4c3 100644
--- a/.github/workflows/vtest.yml
+++ b/.github/workflows/vtest.yml
@@ -89,6 +89,15 @@ jobs:
${{ join(matrix.FLAGS, ' ') }} \
ADDLIB="-Wl,-rpath,/usr/local/lib/ -Wl,-rpath,$HOME/opt/lib/"
sudo make install
+- name: Compile contrib/halog/halog
+ run: |
+make contrib/halog/halog
+- name: Compile contrib/debug/flags
+ run: |
+make contrib/debug/flags
+- name: Compile contrib/debug/poll
+ run: |
+make contrib/debug/poll
- name: Show HAProxy version
id: show-version
run: |
--
2.28.0
Re: [PATCH] BUG/MINOR: contrib/prometheus-exporter: consistent per-server metrics
On Mon, Dec 21, 2020 at 01:05:50PM +0100, William Dauchy wrote:
> > I'm not opposed at all to merging your patch, I'm just worried that
> > some users will then report that these metrics are missing. Or should
> > we duplicate them so that they appear with the two names in older
> > versions maybe ?
>
> There is definitely a (hard) choice to be made here. I'm trying to
> address a case where we collect metrics from different haproxy
> versions and test whether the metric is available or not. Adding more
> metrics along versions is supported but I did not expect to have a
> rename. Duplicating metrics might seem a good middle point but it also
> introduces some confusion for the users looking at available metrics.
> So after a second thought, I realise how things were done with the
> stats socket where we check the version. My conclusion is therefore as
> follow: ignore this patch, and I will most likely propose another one
> which expose the haproxy version in the reported metrics. From that I
> should be able to implement the logic on my side and change the list
> of expected metrics depending on the version.
> This could look like:
> haproxy_process_build_info{version="2.3.2"} 1
> (advices taken from
> https://www.robustperception.io/exposing-the-software-version-to-prometheus)
>
> Does that sound better to you?
This sounds like an excellent idea indeed! I didn't know the version was
not exposed, and for sure sooner or later this version will be needed,
even to distinguish certain metrics whose semantics could have slightly
changed over time for example.
Thanks!
Willy
Re: [PATCH] BUG/MINOR: contrib/prometheus-exporter: consistent per-server metrics
Hi Willy,
Thank you for your answer.
On Mon, Dec 21, 2020 at 11:08 AM Willy Tarreau wrote:
> What impact do you think this renaming can have on stable versions ?
> I suspect the reason it was not backported was to avoid breakage. But
> actually maybe the difference between older and newer versions makes
> the situation even worse.
>
> I'm not opposed at all to merging your patch, I'm just worried that
> some users will then report that these metrics are missing. Or should
> we duplicate them so that they appear with the two names in older
> versions maybe ?
There is definitely a (hard) choice to be made here. I'm trying to
address a case where we collect metrics from different haproxy
versions and test whether the metric is available or not. Adding more
metrics along versions is supported but I did not expect to have a
rename. Duplicating metrics might seem a good middle point but it also
introduces some confusion for the users looking at available metrics.
So after a second thought, I realise how things were done with the
stats socket where we check the version. My conclusion is therefore as
follow: ignore this patch, and I will most likely propose another one
which expose the haproxy version in the reported metrics. From that I
should be able to implement the logic on my side and change the list
of expected metrics depending on the version.
This could look like:
haproxy_process_build_info{version="2.3.2"} 1
(advices taken from
https://www.robustperception.io/exposing-the-software-version-to-prometheus)
Does that sound better to you?
--
William
Re: [PR] hpack-tbl-t.h uses VAR_ARRAY and requires compiler.h to be included
On Mon, Dec 21, 2020 at 12:20:36PM +0100, Christian Ruppert wrote: > > 2) we include from this file so that it becomes > > consistent > > with everything else ; > > > > 3) we add the ifdef VAR_ARRAY directly into the file so that it > > continues > > not to depend on anything and can be directly imported into other > > projects as needed. > > > > I guess I prefer the 3rd option here as it's extremely cheap and will > > keep external build setups very straightforward. What do you think ? > > > > Thanks! > > Willy > > 2. and 3. sounds good. 3. however seems to be the best solution, indeed. OK, do you mind if I just modify your patch and commit message according to this ? Or do you prefer to send a new one ? I'm asking because while I usually have no problem modifying patches or commit messages, I don't do it when they're signed. Thanks, Willy
[ANNOUNCE] haproxy-2.4-dev4
Hi,
HAProxy 2.4-dev4 was released on 2020/12/21. It added 33 new commits
after version 2.4-dev3.
In this traditionally calm period, there aren't that many changes, except
a lot of bug fixes. Actually 3 bugs in dev3 managed to cause crashes on
haproxy.org, this hadn't happened in a very long time. And I'm glad we're
running development versions there because all 3 could be quickly spotted
and fixed :-)
Fixes and cleanups aside, there are still two new features that landed in
dev4:
- the cache is now aware of the number of entries of a similar object
and will currently limit itself to 10 variants of an object so that
we don't fill the whole cache with incompatible variants of a single
object ;
- there is a new "opentracing" filter, entirely hosted in the contrib
directory. It can be built in haproxy by passing USE_OT=1 to the
makefile. Do not ask me how it works, I'm really ignorant of this,
instead, please have a look at the nice and detailed documentation
that my coworker Miroslav has added in that directory (there's even
some doc for developers who want to play with the code). It requires
a C wrapper for opentracing and the opentrafic lib itself but all of
this is explained there. I could verify that it did properly build
even with a cross-compiler before committing it :-)
This last point made me think that we should probably split the contrib
directory into two or 3 parts, because while initially it used to serve
as a place to store non-core stuff, now it contains a bit of everything.
What I'm noticing nowadays is that we can cut it into several parts:
- those which are examples, scripts or tools to be used in complement
with haproxy. We can find the netsnmp monitoring, selinux policies,
plug_qdisc, systemd setup, wireshark dissectors, SPOA examples, etc.
- those that are tools for the developers, like debug, trace, tcploop,
hpack, syntax-highlight, release-estimator, etc.
- those which are add-ons to be linked with the haproxy executable but
which depend on third-party libraries or which are used to interface
with other products but not plain standards. There we have the device
detection engines, prometheus and opentracing addons.
For the first category, I don't think we should change anything.
I think that we should take the second category out of contrib and put
it into "tools" or something like this. We don't need to enforce too many
rules there, each developer is autonomous and will decide to rely on
existing code or not, etc.
For the third category, it would make sense to move this to a new directory
called "addons" or something like this, to make it clear that this code is
optional and will be linked with the haproxy executable. Then we should
standarize the way to build this, so that each of these sub-projects can
include a makefile and be build as part of the main makefile. This would
simplify a lot of stuff. We could then imagine passing the list of addons
in a single variable and be done with it (and even use the reserved name
"all" to include them all). And we'd then move the existing device
detection code src/{51,da,wurfl}.c to their respective directories, making
the maintenance much cleaner in these areas since we could even imagine
having a MAINTAINERS file and a README inside these directory to help
users find what they need. Maybe we should even reserve a section in the
"-vv" output to list all the addons so that regtests could be conditionned
on them in a more generic way.
Just my two cents, I'm interested in anyone's opinion or suggestion here.
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
Wiki : https://github.com/haproxy/wiki/wiki
Sources : http://www.haproxy.org/download/2.4/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.4/src/CHANGELOG
Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/
Willy
---
Complete changelog :
Baptiste Assmann (1):
BUG/MINOR: dns: SRV records ignores duplicated AR records
Christopher Faulet (8):
BUG/MEDIUM: lb-leastconn: Reposition a server using the right eweight
BUG/MEDIUM: mux-h1: Fix a deadlock when a 408 error is pending for a
client
BUG/MINOR: http: Establish a tunnel for all 2xx responses to a CONNECT
BUG/MINOR: mux-h1: Don't set CS_FL_EOI too early for protocol upgrade
requests
BUG/MEDIUM: http-ana: Never for sending data in TUNNEL mode
CLEANUP: mux-h2: Rename h2s_frt_make_resp_data() to be generic
CLEANUP: mux-h2: Rename h2c_frt_handle_data() to be generic
BUG/MEDIUM: mux-h1: Handle h1_process() failures on a pipelined request
Ilya Ship
Re: [PR] hpack-tbl-t.h uses VAR_ARRAY and requires compiler.h to be included
Hey Willy, On 2020-12-21 11:36, Willy Tarreau wrote: Hi, On Sun, Dec 20, 2020 at 12:58:52PM +0500, ??? wrote: ping :) Oh I completely missed this one in the noise it seems! I'm sorry. No problem! :) > Author: Christian Ruppert > Number of patches: 1 > > This is an automated relay of the Github pull request: >hpack-tbl-t.h uses VAR_ARRAY and requires compiler.h to be included I initially tried hard not to put haproxy-specific dependencies in these protocol-specific parts so that they could easily be reused by other projects if needed (hence the relaxed MIT license). But I guess adding compiler.h is not that big of a deal. However I disagree with including it from the same directory with double-quotes, as we try to keep our includes more or less ordered with certain dependencies. Thus Christian, I can offer 3 possibilities here, I don't know which one best suits your use case: 1) we include from this file. It will best follow the current practices all over the code, but may or may not work for your use case depending how you include the file; 2) we include from this file so that it becomes consistent with everything else ; 3) we add the ifdef VAR_ARRAY directly into the file so that it continues not to depend on anything and can be directly imported into other projects as needed. I guess I prefer the 3rd option here as it's extremely cheap and will keep external build setups very straightforward. What do you think ? Thanks! Willy 2. and 3. sounds good. 3. however seems to be the best solution, indeed. -- Regards, Christian Ruppert
Re: [PATCH] speling fixes
On Mon, Dec 21, 2020 at 03:49:08PM +0500, ??? wrote: > te is widely used abbrevation for "transfer encoding" > nd is variable name "name description" > > we need to teach codespell those are legitimate Perfect, makes sense, now applied. Thank you. Willy
Re: [PATCH] speling fixes
пн, 21 дек. 2020 г. в 15:27, Willy Tarreau : > Hi Ilya, > > please could you provide a commit message for this one which is totally > cryptic to me: > > > From c0811d0580d7ff5f5650e17afbc5ecf9d173f772 Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Mon, 21 Dec 2020 01:03:12 +0500 > > Subject: [PATCH 1/3] CI: codespell: whitelist "te" and "nd" words > > > > --- > > .github/workflows/codespell.yml | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/.github/workflows/codespell.yml > b/.github/workflows/codespell.yml > > index c706c4e3d..c75259147 100644 > > --- a/.github/workflows/codespell.yml > > +++ b/.github/workflows/codespell.yml > > @@ -14,4 +14,4 @@ jobs: > > - name: install prerequisites > >run: sudo pip install codespell > > - name: check > > - run: codespell -c -q 2 --ignore-words-list > ist,hist,wan,ca,cas,que,ans --skip="CHANGELOG,*.fig,*.pem" > > + run: codespell -c -q 2 --ignore-words-list > ist,hist,wan,ca,cas,que,ans,te,nd --skip="CHANGELOG,*.fig,*.pem" > > -- > > 2.28.0 > > > > I really have no idea what this does nor why :-( > > No need to resend, if you explain this to me in a few words, I'll add > that into your patch and push it. The two others were already applied. > te is widely used abbrevation for "transfer encoding" nd is variable name "name description" we need to teach codespell those are legitimate > > Thanks! > Willy >
Re: [PR] hpack-tbl-t.h uses VAR_ARRAY and requires compiler.h to be included
Hi, On Sun, Dec 20, 2020 at 12:58:52PM +0500, ??? wrote: > ping :) Oh I completely missed this one in the noise it seems! I'm sorry. > > Author: Christian Ruppert > > Number of patches: 1 > > > > This is an automated relay of the Github pull request: > >hpack-tbl-t.h uses VAR_ARRAY and requires compiler.h to be included I initially tried hard not to put haproxy-specific dependencies in these protocol-specific parts so that they could easily be reused by other projects if needed (hence the relaxed MIT license). But I guess adding compiler.h is not that big of a deal. However I disagree with including it from the same directory with double-quotes, as we try to keep our includes more or less ordered with certain dependencies. Thus Christian, I can offer 3 possibilities here, I don't know which one best suits your use case: 1) we include from this file. It will best follow the current practices all over the code, but may or may not work for your use case depending how you include the file; 2) we include from this file so that it becomes consistent with everything else ; 3) we add the ifdef VAR_ARRAY directly into the file so that it continues not to depend on anything and can be directly imported into other projects as needed. I guess I prefer the 3rd option here as it's extremely cheap and will keep external build setups very straightforward. What do you think ? Thanks! Willy
Re: [PATCH] speling fixes
Hi Ilya, please could you provide a commit message for this one which is totally cryptic to me: > From c0811d0580d7ff5f5650e17afbc5ecf9d173f772 Mon Sep 17 00:00:00 2001 > From: Ilya Shipitsin > Date: Mon, 21 Dec 2020 01:03:12 +0500 > Subject: [PATCH 1/3] CI: codespell: whitelist "te" and "nd" words > > --- > .github/workflows/codespell.yml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/.github/workflows/codespell.yml b/.github/workflows/codespell.yml > index c706c4e3d..c75259147 100644 > --- a/.github/workflows/codespell.yml > +++ b/.github/workflows/codespell.yml > @@ -14,4 +14,4 @@ jobs: > - name: install prerequisites >run: sudo pip install codespell > - name: check > - run: codespell -c -q 2 --ignore-words-list ist,hist,wan,ca,cas,que,ans > --skip="CHANGELOG,*.fig,*.pem" > + run: codespell -c -q 2 --ignore-words-list > ist,hist,wan,ca,cas,que,ans,te,nd --skip="CHANGELOG,*.fig,*.pem" > -- > 2.28.0 > I really have no idea what this does nor why :-( No need to resend, if you explain this to me in a few words, I'll add that into your patch and push it. The two others were already applied. Thanks! Willy
Re: [PR] smp_size and sample_size seems to be mixed in docu
On Thu, Dec 17, 2020 at 11:23:02PM +0100, PR Bot wrote: > Dear list! > > Author: Jan Wagner > Number of patches: 1 > > This is an automated relay of the Github pull request: >smp_size and sample_size seems to be mixed in docu > > Patch title(s): >smp_size and sample_size seems to be mixed (...) Applied, thank you! Willy
Re: [PATCH] DNS: SRV resolution ignores duplicated AR records
On Sat, Dec 19, 2020 at 09:53:38AM +0100, Baptiste wrote: > Hi, > > Since 2.2, HAProxy runtime resolver uses the Additional records of an SRV > response when available. That said, there was a small bug when multiple > records points to the same hostname and IP, then the subsequent ones may > become "unsynchronized". > > This patch fixes this issue. This is also related to github issue 971. > Backport status is 2.2 and above. (...) Applied, thank you Baptiste! Willy
Re: [PATCH] another ssl fine guard (SSL_CTX_get0_privatekey)
On Sat, Dec 19, 2020 at 03:15:27AM +0500, ??? wrote: > Hello, > > another fine guard. Look good, now applied, thank you Ilya! Willy
Re: Quick question on atomics on ARM
Hi David, On Tue, Dec 15, 2020 at 03:54:34PM +, David CARLIER wrote: > Hi, > > I started to look at Haproxy on ARM and stumbled across the > implementation of cpu relax. While it is needed to have such > instruction, I am however wondering if the yield instruction is not > more appropriate than isb in this case ? The use of ISB was suggested by one of the guys in charge of the AWS ARM platform, and in tests it actually performed quite well. It will apparently pause the current CPU for roughly 50 cycles. I have not tested the YIELD instruction however. I suspect based on its description that it's more tailored for some SMT environments (in case that happens one day), and that on other ones it should essentially be a NOP. But this could be tested. Willy
Re: [PATCH] BUG/MINOR: contrib/prometheus-exporter: consistent per-server metrics
Hi William,
On Thu, Dec 17, 2020 at 11:55:18AM +0100, William Dauchy wrote:
> commit c55a626217a7e676e1cc ("MINOR: contrib/prometheus-exporter: Add
> missing global and per-server metrics") is renaming two metrics:
> server_idle_connections_current
> server_idle_connections_limit
>
> This patch to propose to backport this change in 2.2, 2.1. and 2.0 to
> make it consitent accross versions. The main point being, it makes it
> painful to integrate in some automated testing accross versions, which
> make use of those metrics.
What impact do you think this renaming can have on stable versions ?
I suspect the reason it was not backported was to avoid breakage. But
actually maybe the difference between older and newer versions makes
the situation even worse.
I'm not opposed at all to merging your patch, I'm just worried that
some users will then report that these metrics are missing. Or should
we duplicate them so that they appear with the two names in older
versions maybe ?
Thanks,
Willy
