Re: [PATCH] enable coverity daily scan again
чт, 24 дек. 2020 г. в 07:53, Илья Шипицин :
>
>
> чт, 24 дек. 2020 г. в 01:51, Tim Düsterhus :
>
>> Ilya,
>>
>> Am 23.12.20 um 21:21 schrieb Илья Шипицин:
>> > this adds daily job.
>> > token specification also must be done, let us do it after merge.
>>
>> I've cleaned up the YML and commit message a bit:
>>
>> a) Fixed some typos.
>> b) Improved the naming of the Workflow and the workflow steps.
>> c) Add newlines to `apt-get install`.
>> d) Move the `if` out of bash into the YML definition.
>> e) Use `-fsSL` flags for curl to make sure it catches all errors and
>> works for redirects.
>>
>> Can you please check that the changes did not break anything? I attached
>> the updated patch.
>>
>
> I particularly like this one:
>
> if: ${{ env.COVERITY_SCAN_TOKEN != '' }}
>
>
> can it be done job wide ? i.e. nothing should start, neither checkout, nor
> job itself if token is not set (which is true for forks)
>
>
> Also, Tim, I've forgotten to limit builds to "master" branch. Should we
> add some condition as well to prevent coverity scan for other branches ?
>
I'm not sure for Github Actions, we use the following in gitlab for
limiting jobs to parent repo only (i.e. no forks allowed). Is there similar
thing in Github Actions ?
only:refs: - master@haproxy/haproxy
>
>
>>
>> Best regards
>> Tim Düsterhus
>>
>
Re: [PATCH] enable coverity daily scan again
чт, 24 дек. 2020 г. в 01:51, Tim Düsterhus :
> Ilya,
>
> Am 23.12.20 um 21:21 schrieb Илья Шипицин:
> > this adds daily job.
> > token specification also must be done, let us do it after merge.
>
> I've cleaned up the YML and commit message a bit:
>
> a) Fixed some typos.
> b) Improved the naming of the Workflow and the workflow steps.
> c) Add newlines to `apt-get install`.
> d) Move the `if` out of bash into the YML definition.
> e) Use `-fsSL` flags for curl to make sure it catches all errors and
> works for redirects.
>
> Can you please check that the changes did not break anything? I attached
> the updated patch.
>
I particularly like this one:
if: ${{ env.COVERITY_SCAN_TOKEN != '' }}
can it be done job wide ? i.e. nothing should start, neither checkout, nor
job itself if token is not set (which is true for forks)
Also, Tim, I've forgotten to limit builds to "master" branch. Should we
add some condition as well to prevent coverity scan for other branches ?
>
> Best regards
> Tim Düsterhus
>
Re: haproxy hiding url/minio
Hi Chad, On Thu, Dec 24, 2020 at 2:46 PM Jonathan Opperman wrote: > Hi Chad, > > On Thu, Dec 24, 2020 at 2:04 PM Chad Lavoie wrote: > >> Greetings, >> >> On 12/23/2020 7:10 PM, Jonathan Opperman wrote: >> > >> > Works perfectly fine, what is the best way to hide /minio so it will >> > rather say /storage so externally >> > I hide the fact that we are using minio? >> >> You can do that by using 'http-request set-path >> %[regsub(^/storage,/minio)]' to rewrite the path that the backend sees >> from what the client sent. >> > > Thank you for the quick response, appreciate it. Tried to add it but got: > > parsing [/etc/haproxy/haproxy.cfg:172] : error detected in frontend > 'ft_https' while parsing 'http-request set-path' rule : failed to parse > sample expression : unknown fetch method > 'regsub'. > > Should it be: > > http-request set-path %[url,regsub(^/storage,/minio)] > > ? > > Cheers > Jonathan > Answering myself here, it is, and it works :) Thanks for that, appreciate it. Regards, Jonathan > > >> - Chad >> >>
Re: haproxy hiding url/minio
Hi Chad, On Thu, Dec 24, 2020 at 2:04 PM Chad Lavoie wrote: > Greetings, > > On 12/23/2020 7:10 PM, Jonathan Opperman wrote: > > > > Works perfectly fine, what is the best way to hide /minio so it will > > rather say /storage so externally > > I hide the fact that we are using minio? > > You can do that by using 'http-request set-path > %[regsub(^/storage,/minio)]' to rewrite the path that the backend sees > from what the client sent. > Thank you for the quick response, appreciate it. Tried to add it but got: parsing [/etc/haproxy/haproxy.cfg:172] : error detected in frontend 'ft_https' while parsing 'http-request set-path' rule : failed to parse sample expression : unknown fetch method 'regsub'. Should it be: http-request set-path %[url,regsub(^/storage,/minio)] ? Cheers Jonathan > - Chad > >
Re: haproxy hiding url/minio
Greetings, On 12/23/2020 7:10 PM, Jonathan Opperman wrote: Works perfectly fine, what is the best way to hide /minio so it will rather say /storage so externally I hide the fact that we are using minio? You can do that by using 'http-request set-path %[regsub(^/storage,/minio)]' to rewrite the path that the backend sees from what the client sent. - Chad
haproxy hiding url/minio
Hi All, Wanted to get some advice if this is even possible? Want to route https://www.portal.example/minio to a minio instance in the backend. Running haproxy 1.8 configured an acl acl PATH_minio path_beg -i /minio then using backend: use_backend bk_minio_portal if portal PATH_minio backend bk_minio_portal source 0.0.0.0 server 10.11.0.33 10.11.0.33:9000 Works perfectly fine, what is the best way to hide /minio so it will rather say /storage so externally I hide the fact that we are using minio? Thanks in advance for your suggestions :) Cheers Jonathan
Re: [PATCH] enable coverity daily scan again
Ilya,
Am 23.12.20 um 21:21 schrieb Илья Шипицин:
> this adds daily job.
> token specification also must be done, let us do it after merge.
I've cleaned up the YML and commit message a bit:
a) Fixed some typos.
b) Improved the naming of the Workflow and the workflow steps.
c) Add newlines to `apt-get install`.
d) Move the `if` out of bash into the YML definition.
e) Use `-fsSL` flags for curl to make sure it catches all errors and
works for redirects.
Can you please check that the changes did not break anything? I attached
the updated patch.
Best regards
Tim Düsterhus
From 86fab31956b14f39b143d87418c7571642c58201 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Thu, 24 Dec 2020 01:18:04 +0500
Subject: [PATCH] CI: GitHub Actions: enable daily Coverity scan
That scan was previously implemented on Travis. Let us migrate
it to GitHub Actions.
Co-authored-by: Tim Duesterhus
---
.github/workflows/coverity.yml | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 .github/workflows/coverity.yml
diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
new file mode 100644
index 0..38cfa699e
--- /dev/null
+++ b/.github/workflows/coverity.yml
@@ -0,0 +1,27 @@
+name: Coverity
+
+on:
+ schedule:
+- cron: "0 0 * * *"
+
+jobs:
+ scan:
+runs-on: ubuntu-latest
+env:
+ COVERITY_SCAN_PROJECT_NAME: 'Haproxy'
+ COVERITY_SCAN_BRANCH_PATTERN: '*'
+ COVERITY_SCAN_NOTIFICATION_EMAIL: 'chipits...@gmail.com'
+ COVERITY_SCAN_BUILD_COMMAND: "make CC=clang DEFINE=-DDEBUG_USE_ABORT TARGET=linux-glibc USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_WURFL=1 WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl USE_DEVICEATLAS=1 DEVICEATLAS_SRC=contrib/deviceatlas USE_51DEGREES=1 51DEGREES_SRC=contrib/51d/src/pattern DEBUG_STRICT=1"
+steps:
+- uses: actions/checkout@v2
+- name: Install apt dependencies
+ run: |
+sudo apt-get update
+sudo apt-get install -y \
+ liblua5.3-dev \
+ libsystemd-dev
+- name: Run Coverity Scan
+ if: ${{ env.COVERITY_SCAN_TOKEN != '' }}
+ run: |
+make -C contrib/wurfl
+curl -fsSL "https://scan.coverity.com/scripts/travisci_build_coverity_scan.sh; | bash
--
2.29.0
[PATCH] enable coverity daily scan again
Hello,
this adds daily job.
token specification also must be done, let us do it after merge.
Ilya
From 6f52831ee614a334ac5b8ab2c2b29d5e51a681d2 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Thu, 24 Dec 2020 01:18:04 +0500
Subject: [PATCH] CI: Github ACtions: enable daily Coverity scan
that scan was previously implemented on Travis. Let us migrate
it to Github Actions
---
.github/workflows/coverity.yml | 30 ++
1 file changed, 30 insertions(+)
create mode 100644 .github/workflows/coverity.yml
diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
new file mode 100644
index 0..20259d16b
--- /dev/null
+++ b/.github/workflows/coverity.yml
@@ -0,0 +1,30 @@
+
+name: coverity
+
+on:
+ schedule:
+- cron: "0 0 * * *"
+
+jobs:
+ scan:
+
+runs-on: ubuntu-latest
+
+env:
+ COVERITY_SCAN_PROJECT_NAME: 'Haproxy'
+ COVERITY_SCAN_BRANCH_PATTERN: '*'
+ COVERITY_SCAN_NOTIFICATION_EMAIL: 'chipits...@gmail.com'
+ COVERITY_SCAN_BUILD_COMMAND: "make CC=clang DEFINE=-DDEBUG_USE_ABORT TARGET=linux-glibc USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_WURFL=1 WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl USE_DEVICEATLAS=1 DEVICEATLAS_SRC=contrib/deviceatlas USE_51DEGREES=1 51DEGREES_SRC=contrib/51d/src/pattern DEBUG_STRICT=1"
+
+steps:
+- uses: actions/checkout@v2
+- name: install prerequisites
+ run: |
+sudo apt-get update
+sudo apt-get install -y liblua5.3-dev libsystemd-dev
+- name: scan
+ run: |
+if [ ! -z ${COVERITY_SCAN_TOKEN+x} ]; then
+ make -C contrib/wurfl
+ curl -s "https://scan.coverity.com/scripts/travisci_build_coverity_scan.sh; | bash
+fi
--
2.28.0
Wording in home page
Dear list, on http://www.haproxy.org/ : > We always support at least two active versions in parallel and an extra > old one in critical fixes mode only. The currently supported versions > are : Then, all releases to 1.5 are listed. I think we don't support 1.5 anymore :) Could someone fix the wording? Thanks! -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [*EXT*] Re: Quick question on atomics on ARM
On Wed, Dec 23, 2020 at 03:12:38PM +0100, Ionel GARDAIS wrote: > My bad, I wasn't up to date. No worries, a devel version is never up to date by definition! > Olivier's fix is OK : no more CPU hogging. Perfect, thanks for the quick test! Willy
Re: [*EXT*] Re: Quick question on atomics on ARM
My bad, I wasn't up to date. Olivier's fix is OK : no more CPU hogging. -- Ionel - Mail original - De: "Willy Tarreau" À: "Ionel GARDAIS" Cc: "David CARLIER" , "haproxy" Envoyé: Mercredi 23 Décembre 2020 14:52:32 Objet: Re: [*EXT*] Re: Quick question on atomics on ARM On Wed, Dec 23, 2020 at 02:48:17PM +0100, Ionel GARDAIS wrote: > For what it's worth, I tried to build haproxy on Apple M1. > It builds OK but at run, it's stuck in the initial pool_flush, hogging 100% > CPU. > > the assembly part of __ha_cas_dw for __aarch64__ seems to be ignored. What version did you try ? Olivier just fixed an issue related to the macos assembler using ';' as a comment, precisely in __ha_cas_dw :-) Please try again with the latest master from right now. Willy -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: Quick question on atomics on ARM
On Wed, Dec 23, 2020 at 02:48:17PM +0100, Ionel GARDAIS wrote: > For what it's worth, I tried to build haproxy on Apple M1. > It builds OK but at run, it's stuck in the initial pool_flush, hogging 100% > CPU. > > the assembly part of __ha_cas_dw for __aarch64__ seems to be ignored. What version did you try ? Olivier just fixed an issue related to the macos assembler using ';' as a comment, precisely in __ha_cas_dw :-) Please try again with the latest master from right now. Willy
Re: [*EXT*] Re: Quick question on atomics on ARM
For what it's worth, I tried to build haproxy on Apple M1. It builds OK but at run, it's stuck in the initial pool_flush, hogging 100% CPU. the assembly part of __ha_cas_dw for __aarch64__ seems to be ignored. -- Ionel - Mail original - De: "Willy Tarreau" À: "David CARLIER" Cc: "haproxy" Envoyé: Lundi 21 Décembre 2020 11:16:47 Objet: [*EXT*] 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 -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
