[PR] Add 3 features

2023-09-05 Thread PR Bot 
Dear list!

Author: JihoJung 
Number of patches: 1

This is an automated relay of the Github pull request:
   Add 3 features

Patch title(s): 
   Add 3 features

Link:
   https://github.com/haproxy/haproxy/pull/2283

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/2283.patch && vi 2283.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/2283.patch | git am -

Description:
   1) http-request options
  set-proxy-v2-header
  set-
   proxy-v2-tlv-header
   2) server option
  set-proxy-v2-tlv
   3) done memory leakage detection under valgrind
   
   ### do
   nothing
   6205 ==16466== LEAK SUMMARY:
   6206 ==16466==
   definitely lost: 0 bytes in 0 blocks
   6207 ==16466==indirectly
   lost: 0 bytes in 0 blocks
   6208 ==16466==  possibly lost:
   512,353 bytes in 70 blocks
   6209 ==16466==still reachable:
   239,043,476 bytes in 4,231 blocks
   6210 ==16466==
   suppressed: 0 bytes in 0 blocks
   
   ### only http
   6600
   ==18082== LEAK SUMMARY:
   6601 ==18082==definitely lost: 0 bytes
   in 0 blocks
   6602 ==18082==indirectly lost: 0 bytes in 0 blocks
   6603 ==18082==  possibly lost: 622,001 bytes in 146 blocks
   6604 ==18082==still reachable: 239,043,880 bytes in 4,232 blocks
   6605 ==18082== suppressed: 0 bytes in 0 blocks
   6606
   ==18082==
   6607 ==18082== ERROR SUMMARY: 58 errors from 58 contexts
   (suppressed: 0 from 0)
   6608 ==18082== could not unlink /tmp/vgdb-
   pipe-from-vgdb-to-18082-by-root-on-sun
   6609 ==18082== could not
   unlink /tmp/vgdb-pipe-to-vgdb-from-18082-by-root-on-sun
   6610
   ==18082== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-18082-by-
   root-on-sun
   
   ### only accept-proxy and send-proxy-v2
   6895
   ==19881== LEAK SUMMARY:
   6896 ==19881==definitely lost: 0 bytes
   in 0 blocks
   6897 ==19881==indirectly lost: 0 bytes in 0 blocks
   6898 ==19881==  possibly lost: 740,801 bytes in 286 blocks
   6899 ==19881==still reachable: 239,043,476 bytes in 4,231 blocks
   6900 ==19881== suppressed: 0 bytes in 0 blocks
   6901
   ==19881==
   6902 ==19881== ERROR SUMMARY: 77 errors from 77 contexts
   (suppressed: 0 from 0)
   6903 ==19881== could not unlink /tmp/vgdb-
   pipe-from-vgdb-to-19881-by-root-on-sun
   6904 ==19881== could not
   unlink /tmp/vgdb-pipe-to-vgdb-from-19881-by-root-on-sun
   6905
   ==19881== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-19881-by-
   root-on-sun
   
   ### my patch
   6921 ==21025== LEAK SUMMARY:
   6922 ==21025==definitely lost: 0 bytes in 0 blocks
   6923
   ==21025==indirectly lost: 0 bytes in 0 blocks
   6924 ==21025==
   possibly lost: 698,705 bytes in 222 blocks
   6925 ==21025==still
   reachable: 239,048,325 bytes in 4,269 blocks
   6926 ==21025==
   suppressed: 0 bytes in 0 blocks
   6927 ==21025==
   6928 ==21025==
   ERROR SUMMARY: 69 errors from 69 contexts (suppressed: 0 from 0)
   6929 ==21025== could not unlink /tmp/vgdb-pipe-from-vgdb-to-21025-by-
   root-on-sun
   6930 ==21025== could not unlink /tmp/vgdb-pipe-to-
   vgdb-from-21025-by-root-on-sun
   6931 ==21025== could not unlink
   /tmp/vgdb-pipe-shared-mem-vgdb-21025-by-root-on-sun
   
`
   `

Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

2023-09-05 Thread Hopkins, Andrew 
I split up the remaining CI changes into 4 new attached patches. The latest 
changes are still passing on my fork 
https://github.com/andrewhop/haproxy/actions/runs/6090899582.

I was hoping to take advantage of the better HAProxy support in AWS-LC's CI but 
I'm running into some issues in https://github.com/aws/aws-lc/pull/1174 I was 
wondering if you had any pointers of what to look at. I think this is CodeBuild 
specific issue since the tests pass in HAProxy's CI and when I run AWS-LC's CI 
locally. I just can't figure out what CodeBuild might be doing to mess with the 
results.

Looking at the log for mcli_start_progs.vtc the two sleep programs are started 
as expected but the overall process returns the wrong exit code (0x0 instead of 
0x82). Does anything stand out to you as weird looking?

On 9/4/23, 10:02 AM, "William Lallemand" mailto:wlallem...@haproxy.com>> wrote:


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.






On Fri, Sep 01, 2023 at 01:25:55AM +, Hopkins, Andrew wrote:
> Hi,


Hi Andrew!


> I have what I think it approaching the final 3 patches attached. I
> cleaned up the first patch so it just includes the code, makefile, and
> documentation changes to support AWS-LC. The second patch disables the
> one FFDH test when HAPRoxy is build with AWS-LC.


I merged these two ones which are fine.


> Finally, the third patch does a few things:


> 1. Add support to matrix.py to find the latest release of AWS-LC, it
> would be a one line change to add AWS-LC to build on every push in
> matrix.py in the future


> 2. Update matrix.py to have a main function,
> this looks like a big change but is all whitespace. I did this because
> I needed a way to get the latest version in aws-lc.yml. I did that by
> invoking the determine_latest_aws_lc function in the GitHub action,
> I'm open to other suggestions


> 3. Add a weekly build of HAProxy with
> the latest release of AWS-LC with the same schedule as the other
> weekly jobs: Thursdays at 00:00
>


Seems like you just list what could be 3 differents patches in my
opinion. :-) Also this could have been your commit message too!


I didn't merged this one, there is a lot going on in there. It would be
better to split them for better readibility. We encourage to write micro
commits with only one feature per patch.


I'm fine with the final result though, but could you split it in 3
patches? Thanks




> You can see an example of the run here [1]. Also, I discovered you can
> add `workflow_dispatch` to scheduled tasks so you can manually trigger
> them without having to tweak the cron schedule.
>
> [1] https://github.com/andrewhop/haproxy/actions/runs/6044112377 
> 
>


That's great, that will be useful this way!


Thanks


--
William Lallemand





0004-MINOR-ci-Add-a-weekly-CI-run-building-with-AWS-LC.patch
Description: 0004-MINOR-ci-Add-a-weekly-CI-run-building-with-AWS-LC.patch


0003-MINOR-ci-Update-matrix.py-so-all-code-is-contained-i.patch
Description: 0003-MINOR-ci-Update-matrix.py-so-all-code-is-contained-i.patch


0002-MINOR-ci-add-support-to-matrix.py-to-determine-the-l.patch
Description: 0002-MINOR-ci-add-support-to-matrix.py-to-determine-the-l.patch


0001-MINOR-ci-add-support-to-build-ssl.sh-to-download-and.patch
Description: 0001-MINOR-ci-add-support-to-build-ssl.sh-to-download-and.patch

Haproxy Technologies LLC - Interested?

2023-09-05 Thread Joaquin Randolph 
Hey,

Are you paying a lot for phone lines at your company?

I’m from Fistapto & we help companies like yours move to hand-picked
providers with lower rates for your company’s needs. Ringing, messaging,
video-calling and all the whistles.

Want to check this out? Let us know the right manner to reach you to go
over how this works & take this off the ground.

Look forward to connecting.


Best regards,

Joaquin Randolph, Fistapto

[PATCH 1/1] MINOR: promex: Introduce 'NOROOM' status for srv_state metric

2023-09-05 Thread Cedric Paillet 
This adds a new 'noroom' status to the Prometheus metric 'srv_state'. It helps 
identify servers that have exceeded their maxconn limit and cannot accept new 
connections.
---
 addons/promex/service-prometheus.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/addons/promex/service-prometheus.c 
b/addons/promex/service-prometheus.c
index 7b61683dd..4551009d5 100644
--- a/addons/promex/service-prometheus.c
+++ b/addons/promex/service-prometheus.c
@@ -380,6 +380,7 @@ enum promex_srv_state {
PROMEX_SRV_STATE_UP,
PROMEX_SRV_STATE_MAINT,
PROMEX_SRV_STATE_DRAIN,
+   PROMEX_SRV_STATE_NOROOM,
PROMEX_SRV_STATE_NOLB,
 
PROMEX_SRV_STATE_COUNT /* must be last */
@@ -390,10 +391,13 @@ const struct ist promex_srv_st[PROMEX_SRV_STATE_COUNT] = {
[PROMEX_SRV_STATE_UP]= IST("UP"),
[PROMEX_SRV_STATE_MAINT] = IST("MAINT"),
[PROMEX_SRV_STATE_DRAIN] = IST("DRAIN"),
+   [PROMEX_SRV_STATE_NOROOM] = IST("NOROOM"),
[PROMEX_SRV_STATE_NOLB]  = IST("NOLB"),
 };
 
 /* Return the server status. */
+
+
 enum promex_srv_state promex_srv_status(struct server *sv)
 {
int state = PROMEX_SRV_STATE_DOWN;
@@ -402,6 +406,9 @@ enum promex_srv_state promex_srv_status(struct server *sv)
state = PROMEX_SRV_STATE_UP;
if (sv->cur_admin & SRV_ADMF_DRAIN)
state = PROMEX_SRV_STATE_DRAIN;
+   if (!server_has_room(sv))
+   state = PROMEX_SRV_STATE_NOROOM;
+
}
else if (sv->cur_state == SRV_ST_STOPPING)
state = PROMEX_SRV_STATE_NOLB;
-- 
2.25.1

[PATCH 0/1] Introduce 'NOROOM' status for srv_state metric

2023-09-05 Thread Cedric Paillet 
We are using Prometheus to provide feedback to our users about the status of 
backend servers. Currently, we have no means of informing them if a server 
exceeds the maxconn limit, and consequently why it's no longer receiving new 
requests.

Therefore, we would like to be able to display when a server surpasses the 
maxconn limit and is in the "noroom" state. I have prepared a patch 
specifically for Prometheus, but it might be better to include a boolean 
directly in the server structure indicating whether the server was considered 
to have no room the last time server_has_room was called. However, this change 
seems to have a significant impact on other parts of the code.


Cedric Paillet (1):
  MINOR: promex: Introduce 'NOROOM' status for srv_state metric

 addons/promex/service-prometheus.c | 7 +++
 1 file changed, 7 insertions(+)

-- 
2.25.1

Your readers will love this tool

2023-09-05 Thread Grant Polachek 
Hi!

Not sure if you've seen my last few emails about your article HAProxy - The 
Reliable, High Performance TCP/HTTP Load Balancer

If not, no worries! I wanted to reach out again because I think your readers 
will get a lot of value out of our free trademark tool 
https://www.squadhelp.com/check-trademark. 

Your readers will love this tool because:

 1. It's completely free and available to all entrepreneurs and small business 
owners, despite costing Squadhelp money for every use.
 2. The tool searches multiple databases, including USPTO, Canadian, European, 
and Australian databases, with plans to expand further in the future.
 3. It provides intelligent close-match trademarks as well as exact matches, 
allowing users to make informed decisions about their name's uniqueness both 
legally and from a marketing perspective.


Would you be interested in linking Squadhelp’s Trademark Checker in your 
article or other content you might have on trademarks or naming? Please let me 
know!

Looking forward to hearing back from you.
 
Best,
Grant Polachek
Head of Branding | Squadhelp.com //Squadhelp.com 
Phone: (443) 782-5272
2000 Center Drive, Suite East C221, Hoffman Estates, IL 60192 United States

picture [https://track.squadhelp.co/tmid_a/JgNMDCzkhfNyZtzi4Une4] logo 
[https://track.squadhelp.co/tmid_a/JgNMDCzkhfNyZtzi4Une4]