Re: Hello HAProxy Team! I have a question about one of your posts...

2021-09-12 Thread Vanessa Diwa
Hi HAProxy Team,

I reached out a few days back regarding your remarkable post. Just checking
in to see if you have received my previous email regarding your article
https://www.haproxy.com/blog/power-your-consul-service-mesh-with-haproxy/
since I haven't received any feedback.

I would love to know if you are interested in adding our article
https://www.toptal.com/kubernetes/service-mesh-comparison as a resource to
your post?

You see we are hoping you can add our article as an additional resource to
your article. I believe our article goes well together and that it will
benefit your readers to know more about the article topic. One of Toptal's
goals is to provide more helpful information about the topic to others by
connecting our articles to other expert's articles like yours :)

Also, one of the most interesting benefits for you when adding our link
would be the fact that Google loves freshly updated content and tend to
rank such articles better.  As a result, this could help increase the
ranking of your article for this topic -

   - Links are Important – Linking out to pages along the same subject
   matter will give an enormous boost to your Google rankings.
   - External links ARE good for SEO and it’s widely accepted that external
   links are one of the most important metrics for high-position ranking.
   - External links are the most important source of ranking power.
   - Valuable external links will also help to improve the authority of
   your website, by providing a viewer with references.


Looking forward to hearing from you!


Cheers,
Vanessa


-Original Message-

Hi HAProxy Team,

Vanessa from Toptal here! I promise this will be quick. I just read one of
your posts -
https://www.haproxy.com/blog/power-your-consul-service-mesh-with-haproxy/
and I was hoping that we could connect.

I totally agree when you mention that Kubernetes makes configuring a
service mesh easier tactically because you can run multiple containers
inside a single pod, which is often referred to as running sidecar
containers.

When discussing microservices architecture and containerization, one set of
production-proven tools has captured most of the attention in recent years:
the service mesh.

Would you be interested in adding this as an additional resource to your
article? It will be a great update especially to your readers that are
interested in the Kubernetes service.

Here is the link for your reference:
https://www.toptal.com/kubernetes/service-mesh-comparison

Looking forward to hearing your thoughts on this and stay safe always.

Regards,
Vanessa


Re: [ANNOUNCE] haproxy-2.5-dev7

2021-09-12 Thread Willy Tarreau
Hi Dmitry,

On Sun, Sep 12, 2021 at 05:54:33PM +0300, Dmitry Sivachenko wrote:
> there is a new warning in -dev branch (on FreeBSD):
> 
> admin/halog/fgets2.c:38:30: warning: '__GLIBC__' is not defined, evaluates to 
> 0 [-Wundef]
> #if defined(__x86_64__) &&  (__GLIBC__ > 2 || (__GLIBC__ == 2 && 
> __GLIBC_MINOR__ >= 15))
>  ^
> admin/halog/fgets2.c:38:48: warning: '__GLIBC__' is not defined, evaluates to 
> 0 [-Wundef]
> #if defined(__x86_64__) &&  (__GLIBC__ > 2 || (__GLIBC__ == 2 && 
> __GLIBC_MINOR__ >= 15))
> 
> Looks like Linux-specific condition.

Ah thank you! Another one I missed. I'll fix it, it's caused by the addition
of -Wundef.

Willy



Re: [ANNOUNCE] haproxy-2.5-dev7

2021-09-12 Thread Dmitry Sivachenko



> On 12 Sep 2021, at 13:06, Willy Tarreau  wrote:
> 
> Hi,
> 
> HAProxy 2.5-dev7 was released on 2021/09/12. It added 39 new commits
> after version 2.5-dev6.



Hello,

there is a new warning in -dev branch (on FreeBSD):

admin/halog/fgets2.c:38:30: warning: '__GLIBC__' is not defined, evaluates to 0 
[-Wundef]
#if defined(__x86_64__) &&  (__GLIBC__ > 2 || (__GLIBC__ == 2 && 
__GLIBC_MINOR__ >= 15))
 ^
admin/halog/fgets2.c:38:48: warning: '__GLIBC__' is not defined, evaluates to 0 
[-Wundef]
#if defined(__x86_64__) &&  (__GLIBC__ > 2 || (__GLIBC__ == 2 && 
__GLIBC_MINOR__ >= 15))

Looks like Linux-specific condition.

Thanks.


Re: [ANNOUNCE] haproxy-2.5-dev7

2021-09-12 Thread Tim Düsterhus

Willy,

On 9/12/21 12:06 PM, Willy Tarreau wrote:

Tim Duesterhus (3):
   CLEANUP: Add haproxy/xxhash.h to avoid modifying import/xxhash.h
   CLEANUP: Move XXH3 macro from haproxy/compat.h to haproxy/xxhash.h
   BUG/MEDIUM lua: Add missing call to RESET_SAFE_LJMP in hlua_filter_new()

Tim Düsterhus (1):
   CLEANUP: ebmbtree: Replace always-taken elseif by else


I'm annoyed that I appear twice. Consider applying the attached UTF-8 
encoded (!) patch to fix that.


The .mailmap in base64 is:

VGltIETDvHN0ZXJodXMgPHRpbUBiYXN0ZWxzdHUuYmU+Cg==

with hash:

SHA256 (.mailmap) = 
a8134231950cd8733a21770538747516394b1b8ba7b1ac32e85e7d70d9c8cd99


Best regards
Tim Düsterhus
>From 28f0740576947b0f4b2a78677142d0e6d408221b Mon Sep 17 00:00:00 2001
From: Tim Duesterhus 
Date: Sun, 12 Sep 2021 15:55:04 +0200
Subject: [PATCH] DOC: Add .mailmap
To: haproxy@formilux.org
Cc: w...@1wt.eu

Ensure that Tim's last name is consistent no matter how the patch is generated
and applied, preventing Tim from showing up as two different persons in the
shortlog in releases.
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 .mailmap

diff --git a/.mailmap b/.mailmap
new file mode 100644
index 0..82cb385ae
--- /dev/null
+++ b/.mailmap
@@ -0,0 +1 @@
+Tim Düsterhus 
-- 
2.33.0



[PATCH] Huge number of cleanup patches

2021-09-12 Thread Tim Düsterhus

Willy,

please find 42 patches attached. Sending as attachments to not 
completely bomb the list.


I'll leave it up to you whether you want to squash patches 0001 until 0041.

0042 is sufficiently different to warrant a dedicated commit.

Best regards
Tim Düsterhus
>From 87ca986b06663344bdb18b1db5ca69c74145a56c Mon Sep 17 00:00:00 2001
From: Tim Duesterhus 
Date: Sun, 12 Sep 2021 12:49:33 +0200
Subject: [PATCH 01/42] CLEANUP: Fix prototype of ha_backtrace_to_stderr()
To: haproxy@formilux.org
Cc: w...@1wt.eu

Explicitly indicate the empty parameter list.
---
 include/haproxy/bug.h   | 4 ++--
 include/haproxy/debug.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/haproxy/bug.h b/include/haproxy/bug.h
index 7a2fa81a0..45c97ba67 100644
--- a/include/haproxy/bug.h
+++ b/include/haproxy/bug.h
@@ -39,12 +39,12 @@
 
 #ifdef DEBUG_USE_ABORT
 /* abort() is better recognized by code analysis tools */
-#define ABORT_NOW() do { extern void ha_backtrace_to_stderr(); ha_backtrace_to_stderr(); abort(); } while (0)
+#define ABORT_NOW() do { extern void ha_backtrace_to_stderr(void); ha_backtrace_to_stderr(); abort(); } while (0)
 #else
 /* More efficient than abort() because it does not mangle the
   * stack and stops at the exact location we need.
   */
-#define ABORT_NOW() do { extern void ha_backtrace_to_stderr(); ha_backtrace_to_stderr(); (*(volatile int*)1=0); } while (0)
+#define ABORT_NOW() do { extern void ha_backtrace_to_stderr(void); ha_backtrace_to_stderr(); (*(volatile int*)1=0); } while (0)
 #endif
 
 /* BUG_ON: complains if  is true when DEBUG_STRICT or DEBUG_STRICT_NOCRASH
diff --git a/include/haproxy/debug.h b/include/haproxy/debug.h
index dd1668db9..c6bdd7c5d 100644
--- a/include/haproxy/debug.h
+++ b/include/haproxy/debug.h
@@ -29,7 +29,7 @@ extern unsigned int debug_commands_issued;
 void ha_task_dump(struct buffer *buf, const struct task *task, const char *pfx);
 void ha_thread_dump(struct buffer *buf, int thr, int calling_tid);
 void ha_dump_backtrace(struct buffer *buf, const char *prefix, int dump);
-void ha_backtrace_to_stderr();
+void ha_backtrace_to_stderr(void);
 void ha_thread_dump_all_to_trash();
 void ha_panic();
 
-- 
2.33.0

>From d3057dd6d1ab2c4bf0018b08ba25b95689048b1e Mon Sep 17 00:00:00 2001
From: Tim Duesterhus 
Date: Sun, 12 Sep 2021 00:34:34 +0200
Subject: [PATCH 02/42] CLEANUP: Fix prototype of ha_cpuset_size()
To: haproxy@formilux.org
Cc: w...@1wt.eu

Explicitly indicate the empty parameter list.
---
 include/haproxy/cpuset.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/haproxy/cpuset.h b/include/haproxy/cpuset.h
index d29c3560b..390115bcd 100644
--- a/include/haproxy/cpuset.h
+++ b/include/haproxy/cpuset.h
@@ -39,6 +39,6 @@ void ha_cpuset_assign(struct hap_cpuset *dst, const struct hap_cpuset *src);
 
 /* Returns the biggest index plus one usable on the platform.
  */
-int ha_cpuset_size();
+int ha_cpuset_size(void);
 
 #endif /* _HAPROXY_CPUSET_H */
-- 
2.33.0

>From c259a76dd9474a0a4e30982767144248ed350b84 Mon Sep 17 00:00:00 2001
From: Tim Duesterhus 
Date: Sun, 12 Sep 2021 12:50:04 +0200
Subject: [PATCH 03/42] CLEANUP: Fix prototype of ha_panic()
To: haproxy@formilux.org
Cc: w...@1wt.eu

Explicitly indicate the empty parameter list.
---
 include/haproxy/debug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/haproxy/debug.h b/include/haproxy/debug.h
index c6bdd7c5d..6d5eba6b8 100644
--- a/include/haproxy/debug.h
+++ b/include/haproxy/debug.h
@@ -31,6 +31,6 @@ void ha_thread_dump(struct buffer *buf, int thr, int calling_tid);
 void ha_dump_backtrace(struct buffer *buf, const char *prefix, int dump);
 void ha_backtrace_to_stderr(void);
 void ha_thread_dump_all_to_trash();
-void ha_panic();
+void ha_panic(void);
 
 #endif /* _HAPROXY_DEBUG_H */
-- 
2.33.0

>From cb39d1db9aa527c5ea57d084565abf7eff6da894 Mon Sep 17 00:00:00 2001
From: Tim Duesterhus 
Date: Sun, 12 Sep 2021 01:12:21 +0200
Subject: [PATCH 04/42] CLEANUP: Fix prototype of ha_random64()
To: haproxy@formilux.org
Cc: w...@1wt.eu

Explicitly indicate the empty parameter list.
---
 include/haproxy/tools.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/haproxy/tools.h b/include/haproxy/tools.h
index dec82e6b7..341a93e70 100644
--- a/include/haproxy/tools.h
+++ b/include/haproxy/tools.h
@@ -1027,7 +1027,7 @@ int parse_dotted_uints(const char *s, unsigned int **nums, size_t *sz);
 void ha_generate_uuid(struct buffer *output);
 void ha_random_seed(const unsigned char *seed, size_t len);
 void ha_random_jump96(uint32_t dist);
-uint64_t ha_random64();
+uint64_t ha_random64(void);
 
 static inline uint32_t ha_random32()
 {
-- 
2.33.0

>From 11ee1f68b4ad932499e4347f5c6749ca833b936c Mon Sep 17 00:00:00 2001
From: Tim Duesterhus 
Date: Sun, 12 Sep 2021 12:50:26 +0200
Subject: [PATCH 05/42] CLEANUP: Fix prototype of ha_thread_dump_all_to_trash()
To: haproxy@formilux.org
Cc: w...@1wt.eu

Explicitly indicate the 

[ANNOUNCE] haproxy-2.5-dev7

2021-09-12 Thread Willy Tarreau
Hi,

HAProxy 2.5-dev7 was released on 2021/09/12. It added 39 new commits
after version 2.5-dev6.

This version is essentially released to flush the pipe of pending fixes
for 2.5-dev. It contains the fix for CVE-2021-40346, plus a few other
ones related to option abortonclose.

The infamous global names array for the variables was finally eliminated
(which led me to break OpenTracing but Miroslav fixed it by temporarily
disabling the support for variables there). Now the "ifexist" restrictions
in Lua or SPOE only apply to the "proc" scope, so that all ephemeral
variables are not affected by this restriction and are easiler to deal
with. Variables under the scope "proc" that are declared in the config
are marked "permanent" so that they continue to work like before and do
not need to be explicitly created first. This leads me to think that the
"ifexist" argument of the Lua's set_var() could possibly be turned on by
default so that existing code using variables is made safe by default
without having to be modified, but could accept an explicit zero in the
argument to enforce creation of random names under the "proc" scope. But
I could be wrong, I think that those using them know better than me. Thanks
to these cleanups and a few other ones that allowed not to take the
variables lock when not needed, the cost of variables manipulation has
significantly dropped to the point that the request rate on a 16-thread
machine using 12 variables almost doubled.

A new "grace" global keyword was added to replace the per-proxy one that
was removed in 2.5. Some users needed something to maintain the process
alive for a few extra seconds after signal delivery, for the very same
reason that drove this keyword to be added a long time ago (i.e. no reload,
process is always totally stopped but watched by an external agent). It's
a good compromise in my opinion and even does the job better than before
without the previous trouble of half-closed listeners.

And the rest are mostly cleanups.

As a reminder, if you have sensitive changes pending please post them
before the 15th so that we can get all the tricky stuff reviewed and
merged before the 30th. I'm aware that some developers will possibly be
busy preparing their talk for the conference that comes in two months,
so I expect a bit less bandwidth for reviews and fixes in the upcoming
weeks. By the way, by "sensitive changes", I mean anything that may
significantly affect build or stability of non-experimental stuff, as
well as a change of configuration. The variables stuff I just merged
qualifies, for example. I'll try to get some minimalistic thread-group
support by then, but with absolutely no guarantees given all the stuff
that remains to be done.

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.5/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.5/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Christopher Faulet (7):
  Revert "BUG/MINOR: stream-int: Don't block reads in si_update_rx() if chn 
may receive"
  BUG/MEDIUM: mux-h1: Remove "Upgrade:" header for requests with payload
  MINOR: htx: Skip headers with no value when adding a header list to a 
message
  CLEANUP: mux-h1: Remove condition rejecting upgrade requests with payload
  BUG/MEDIUM: stream-int: Don't block SI on a channel policy if EOI is 
reached
  BUG/MEDIUM: http-ana: Reset channels analysers when returning an error
  BUG/MINOR: filters: Set right FLT_END analyser depending on channel

Miroslav Zagorac (5):
  BUILD: opentracing: exclude the use of haproxy variables for the 
OpenTracing context
  BUG/MINOR: opentracing: enable the use of http headers without a set value
  CLEANUP: opentracing: use the haproxy function to generate uuid
  MINOR: opentracing: change the scope of the variable 'ot.uuid' from 
'sess' to 'txn'
  CLEANUP: opentracing: simplify the condition on the empty header

Tim Duesterhus (3):
  CLEANUP: Add haproxy/xxhash.h to avoid modifying import/xxhash.h
  CLEANUP: Move XXH3 macro from haproxy/compat.h to haproxy/xxhash.h
  BUG/MEDIUM lua: Add missing call to RESET_SAFE_LJMP in hlua_filter_new()

Tim Düsterhus (1):
  CLEANUP: ebmbtree: Replace always-taken elseif by else

Willy Tarreau (22):
  BUG/MINOR: config: reject configs using HTTP with bufsize >= 256 MB
  CLEANUP: htx: remove comments about "must be < 256 MB"
  BUG/MAJOR: htx: fix missing header name length check in 
htx_add_header/trailer
  MINOR: proxy: 

Re: [PATCH 2/4] BUG/MINOR: opentracing: enable the use of http headers without a set value

2021-09-12 Thread Miroslav Zagorac

Hello Willy,

On 09/12/2021 08:19 AM, Willy Tarreau wrote:

Bah, I discovered that one after merging the first series :-/ I've
applied it on top as a cleanup with your description above as the
commit message since it's really what it's about.


It is no problem.  I apologize for the slight confusion.

--
Zaga

What can change the nature of a man?



Re: [PATCH] BUILD: opentracing: excluded use of haproxy variables for, OpenTracing context

2021-09-12 Thread Miroslav Zagorac

Hello Willy,

On 09/12/2021 08:11 AM, Willy Tarreau wrote:

thanks for working on fixing this, it's now merged. I've added a
tiny change to make sure that text_map is always initialized in
flt_ot_scope_run() because that made clang rightfully upset,
re-enabled OT in the CI since it's now OK.


Right, it's necessary, I overlooked it and the gcc didn't object.

Thanks.

--
Zaga

What can change the nature of a man?



Re: [PATCH] BUG/???: lua: Add missing call to RESET_SAFE_LJMP in hlua_filter_new()

2021-09-12 Thread Willy Tarreau
On Sat, Sep 11, 2021 at 11:17:25PM +0200, Tim Duesterhus wrote:
> In one case before exiting leaving the function the panic handler was not
> reset.
> 
> Introduced in 69c581a09271e91d306e7b9080502a36abdc415e, which is 2.5+.
> No backport required.

Good catch, applied as medium since it seems none of us can clearly
predict the effect :-)

Thanks!
Willy



Re: [PATCH 2/4] BUG/MINOR: opentracing: enable the use of http headers without a set value

2021-09-12 Thread Willy Tarreau
On Sat, Sep 11, 2021 at 12:27:30AM +0200, Miroslav Zagorac wrote:
> On 09/11/2021 12:05 AM, Miroslav Zagorac wrote:
> > Hello all,
> > 
> > the second patch from the last series of patches has been redesigned
> > here, the ist() function is used to set an empty string instead of
> > working directly with the string pointer.
> > 
> > I thank Tim Düsterhus for his advice.
> 
> The operation comment has been slightly corrected.
> Sorry to bother you.  :)

Bah, I discovered that one after merging the first series :-/ I've
applied it on top as a cleanup with your description above as the
commit message since it's really what it's about.

Thanks,
Willy



Re: [PATCH] BUILD: opentracing: excluded use of haproxy variables for, OpenTracing context

2021-09-12 Thread Willy Tarreau
Hi guys,

thanks for working on fixing this, it's now merged. I've added a
tiny change to make sure that text_map is always initialized in
flt_ot_scope_run() because that made clang rightfully upset,
re-enabled OT in the CI since it's now OK.

Cheers,
Willy