Re: do we want to keep CentOS 6 builds?
I was able to use vault repo on my CentOS 6 vm (I mentioned that earlier).
if someone wishes to invest dedicated builder vm, we can attach it to
Github Actions.
as for "another oldish but maintained distro", I'll have a look
ср, 16 дек. 2020 г. в 13:43, Willy Tarreau :
> On Wed, Dec 16, 2020 at 01:16:02PM +0500, ??? wrote:
> > let us drop builds.
> > when someone will invest into it, we'll bring em back.
>
> Applied, thank you Ilya. Indeed, it's better if we get rid of these
> permanent failures for now until someone figures a different option.
> Also, note that it doesn't necessarily have to be centos 6, any old
> but still maintained OS from the same era can be fine to spot build
> issues caused by accidental linuxisms or bad assumptions about some
> environments.
>
> That's exactly why I'm keeping this old AIX 5.1+openssl 1.0.2 machine
> up and running, it managed to spot bugs in every single version before
> the final release. It just takes ages to build (~5 minutes at -O0) and
> any alternative would be nice. E.g:
>
> $ ./haproxy -vv
> HA-Proxy version 2.3-dev6-6b736b447 2020/10/11 - https://haproxy.org/
> Status: development branch - not safe for use in production.
> Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
> Running on: AIX 1 5 00514D3A4C00
> Build options :
> TARGET = aix51
> CPU = generic
> CC = gcc
> CFLAGS = -O0 -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv
> -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered
> -Wno-missing-field-initializers -Wtype-limits -Dss_family=__ss_family
> -Dip6_hdr=ip6hdr -DSTEVENS_API -D_LINUX_SOURCE_COMPAT -Dunsetenv=my_unsetenv
> OPTIONS = USE_OPENSSL=1
>
> Feature list : -EPOLL -KQUEUE -NETFILTER -PCRE -PCRE_JIT -PCRE2
> -PCRE2_JIT +POLL +PRIVATE_CACHE -THREAD -PTHREAD_PSHARED -BACKTRACE
> -STATIC_PCRE -STATIC_PCRE2 -TPROXY -LINUX_TPROXY -LINUX_SPLICE +LIBCRYPT
> -CRYPT_H -GETADDRINFO +OPENSSL -LUA -FUTEX -ACCEPT4 -CLOSEFROM -ZLIB -SLZ
> -CPU_AFFINITY -TFO -NS -DL -RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD
> +OBSOLETE_LINKER -PRCTL -THREAD_DUMP -EVPORTS
>
> Default settings :
> bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Built with OpenSSL version : OpenSSL 1.0.2n 7 Dec 2017
> Running on OpenSSL version : OpenSSL 1.0.2n 7 Dec 2017
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
> Built without compression support (neither USE_ZLIB nor USE_SLZ are set).
> Compression algorithms supported : identity("identity")
> Built without multi-threading support (USE_THREAD not set).
> Built without PCRE or PCRE2 support (using libc's regex instead)
> Encrypted password support via crypt(3): yes
> Built with transparent proxy support using:
> Built with gcc compiler version 4.5.4
> Built with transparent proxy support using:
>
> Available polling systems :
> poll : pref=200, test result OK
>select : pref=150, test result OK
> Total: 2 (2 usable), will use poll.
>
> Available multiplexer protocols :
> (protocols marked as cannot be specified using 'proto' keyword)
> fcgi : mode=HTTP side=BEmux=FCGI
> : mode=HTTP side=FE|BE mux=H1
> h2 : mode=HTTP side=FE|BE mux=H2
> : mode=TCPside=FE|BE mux=PASS
>
> Available services : none
>
> Available filters :
> [SPOE] spoe
> [COMP] compression
> [TRACE] trace
> [CACHE] cache
> [FCGI] fcgi-app
>
> Willy
>
Re: do we want to keep CentOS 6 builds?
On Wed, Dec 16, 2020 at 01:16:02PM +0500, ??? wrote:
> let us drop builds.
> when someone will invest into it, we'll bring em back.
Applied, thank you Ilya. Indeed, it's better if we get rid of these
permanent failures for now until someone figures a different option.
Also, note that it doesn't necessarily have to be centos 6, any old
but still maintained OS from the same era can be fine to spot build
issues caused by accidental linuxisms or bad assumptions about some
environments.
That's exactly why I'm keeping this old AIX 5.1+openssl 1.0.2 machine
up and running, it managed to spot bugs in every single version before
the final release. It just takes ages to build (~5 minutes at -O0) and
any alternative would be nice. E.g:
$ ./haproxy -vv
HA-Proxy version 2.3-dev6-6b736b447 2020/10/11 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Running on: AIX 1 5 00514D3A4C00
Build options :
TARGET = aix51
CPU = generic
CC = gcc
CFLAGS = -O0 -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered
-Wno-missing-field-initializers -Wtype-limits -Dss_family=__ss_family
-Dip6_hdr=ip6hdr -DSTEVENS_API -D_LINUX_SOURCE_COMPAT -Dunsetenv=my_unsetenv
OPTIONS = USE_OPENSSL=1
Feature list : -EPOLL -KQUEUE -NETFILTER -PCRE -PCRE_JIT -PCRE2 -PCRE2_JIT
+POLL +PRIVATE_CACHE -THREAD -PTHREAD_PSHARED -BACKTRACE -STATIC_PCRE
-STATIC_PCRE2 -TPROXY -LINUX_TPROXY -LINUX_SPLICE +LIBCRYPT -CRYPT_H
-GETADDRINFO +OPENSSL -LUA -FUTEX -ACCEPT4 -CLOSEFROM -ZLIB -SLZ -CPU_AFFINITY
-TFO -NS -DL -RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD +OBSOLETE_LINKER
-PRCTL -THREAD_DUMP -EVPORTS
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : OpenSSL 1.0.2n 7 Dec 2017
Running on OpenSSL version : OpenSSL 1.0.2n 7 Dec 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built without compression support (neither USE_ZLIB nor USE_SLZ are set).
Compression algorithms supported : identity("identity")
Built without multi-threading support (USE_THREAD not set).
Built without PCRE or PCRE2 support (using libc's regex instead)
Encrypted password support via crypt(3): yes
Built with transparent proxy support using:
Built with gcc compiler version 4.5.4
Built with transparent proxy support using:
Available polling systems :
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 2 (2 usable), will use poll.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
fcgi : mode=HTTP side=BEmux=FCGI
: mode=HTTP side=FE|BE mux=H1
h2 : mode=HTTP side=FE|BE mux=H2
: mode=TCPside=FE|BE mux=PASS
Available services : none
Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
[CACHE] cache
[FCGI] fcgi-app
Willy
Re: do we want to keep CentOS 6 builds?
let us drop builds.
when someone will invest into it, we'll bring em back.
Ilya
вт, 8 дек. 2020 г. в 15:08, Илья Шипицин :
> I played with various options.
> while things work well on my personal centos 6 vm, they still do not work
> on cirrus
>
> https://github.com/chipitsine/haproxy/blob/master/.cirrus.yml#L21-L22
> (we cannot use yum-config-manager --add-repo=..., because
> yum-config-manager is not installed)
>
> build:
> https://cirrus-ci.com/task/4596651333517312
>
> any ideas what to try ?
>
> чт, 3 дек. 2020 г. в 10:48, Илья Шипицин :
>
>> I'll check on weekend whether we can switch to vault repo
>>
>> чт, 3 дек. 2020 г. в 02:48, Willy Tarreau :
>>
>>> On Wed, Dec 02, 2020 at 10:29:03PM +0100, Adis Nezirovic wrote:
>>> > On 12/2/20 9:45 PM, Willy Tarreau wrote:
>>> > > On Wed, Dec 02, 2020 at 10:19:47PM +0500, ??? wrote:
>>> > > > seems, CentOS 6 packages were removed from mirrors
>>> > > >
>>> > > > https://cirrus-ci.com/task/5915513668763648
>>> > >
>>> > > I've never understood why some distros do something that stupid. They
>>> > > even prevent some people from setting up a backup server in
>>> emergency.
>>> > >
>>> > > So does this mean we'll drop this one ?
>>> >
>>> > For what it's worth, after EOL, data is moved to CentOS vault:
>>> >
>>> > https://vault.centos.org/6.10/
>>>
>>> Thanks Adis. Not sure what this implies for setup scripts, but
>>> it's good to know.
>>>
>>> Willy
>>>
>>
From 9283fb131affc6f71e9d0511bdeec054f56b22ec Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Wed, 16 Dec 2020 13:06:53 +0500
Subject: [PATCH] CI: cirrus: drop CentOS 6 builds
CentOS 6 packages were removed from repo. Also, I was not able
to get it working using centos vault.
Further discussion on ML:
https://www.mail-archive.com/haproxy@formilux.org/msg38908.html
---
.cirrus.yml | 17 -
1 file changed, 17 deletions(-)
diff --git a/.cirrus.yml b/.cirrus.yml
index 970ab3ae4..e8b70de6d 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -12,20 +12,3 @@ FreeBSD_task:
- ./haproxy -vv
- ldd haproxy
- env VTEST_PROGRAM=../vtest/vtest gmake reg-tests REGTESTS_TYPES=default,bug,devel || (for folder in /tmp/*regtest*/vtc.*; do cat $folder/INFO $folder/LOG; done && exit 1)
-
-centos_6_task:
- container:
-image: centos:centos6
- only_if: $CIRRUS_BRANCH =~ 'master|next'
- script:
-- yum install -q -y gcc git openssl-devel pcre-devel epel-release socat
-- yum install -q -y python34
-- git clone https://github.com/VTest/VTest.git ../vtest
-# Special flags due to: https://github.com/vtest/VTest/issues/12
-- make -C ../vtest FLAGS="-O2 -s -Wall -lrt"
-- make CC=cc V=1 TARGET=linux-glibc-legacy USE_ZLIB=1 USE_PCRE=1 USE_OPENSSL=1
-- ./haproxy -vv
-- ldd haproxy
-# remove some reg-tests (CentOS 6 does not support alpn)
-- rm reg-tests/{connection/proxy_protocol_random_fail,checks/tcp-check-ssl,connection/proxy_protocol_send_unique_id_alpn}.vtc
-- env VTEST_PROGRAM=../vtest/vtest make reg-tests REGTESTS_TYPES=default,bug,devel || (for folder in /tmp/*regtest*/vtc.*; do cat $folder/INFO $folder/LOG; done && exit 1)
--
2.28.0
Re: do we want to keep CentOS 6 builds?
I played with various options. while things work well on my personal centos 6 vm, they still do not work on cirrus https://github.com/chipitsine/haproxy/blob/master/.cirrus.yml#L21-L22 (we cannot use yum-config-manager --add-repo=..., because yum-config-manager is not installed) build: https://cirrus-ci.com/task/4596651333517312 any ideas what to try ? чт, 3 дек. 2020 г. в 10:48, Илья Шипицин : > I'll check on weekend whether we can switch to vault repo > > чт, 3 дек. 2020 г. в 02:48, Willy Tarreau : > >> On Wed, Dec 02, 2020 at 10:29:03PM +0100, Adis Nezirovic wrote: >> > On 12/2/20 9:45 PM, Willy Tarreau wrote: >> > > On Wed, Dec 02, 2020 at 10:19:47PM +0500, ??? wrote: >> > > > seems, CentOS 6 packages were removed from mirrors >> > > > >> > > > https://cirrus-ci.com/task/5915513668763648 >> > > >> > > I've never understood why some distros do something that stupid. They >> > > even prevent some people from setting up a backup server in emergency. >> > > >> > > So does this mean we'll drop this one ? >> > >> > For what it's worth, after EOL, data is moved to CentOS vault: >> > >> > https://vault.centos.org/6.10/ >> >> Thanks Adis. Not sure what this implies for setup scripts, but >> it's good to know. >> >> Willy >> >
Re: do we want to keep CentOS 6 builds?
I'll check on weekend whether we can switch to vault repo чт, 3 дек. 2020 г. в 02:48, Willy Tarreau : > On Wed, Dec 02, 2020 at 10:29:03PM +0100, Adis Nezirovic wrote: > > On 12/2/20 9:45 PM, Willy Tarreau wrote: > > > On Wed, Dec 02, 2020 at 10:19:47PM +0500, ??? wrote: > > > > seems, CentOS 6 packages were removed from mirrors > > > > > > > > https://cirrus-ci.com/task/5915513668763648 > > > > > > I've never understood why some distros do something that stupid. They > > > even prevent some people from setting up a backup server in emergency. > > > > > > So does this mean we'll drop this one ? > > > > For what it's worth, after EOL, data is moved to CentOS vault: > > > > https://vault.centos.org/6.10/ > > Thanks Adis. Not sure what this implies for setup scripts, but > it's good to know. > > Willy >
Re: do we want to keep CentOS 6 builds?
On Wed, Dec 02, 2020 at 10:29:03PM +0100, Adis Nezirovic wrote: > On 12/2/20 9:45 PM, Willy Tarreau wrote: > > On Wed, Dec 02, 2020 at 10:19:47PM +0500, ??? wrote: > > > seems, CentOS 6 packages were removed from mirrors > > > > > > https://cirrus-ci.com/task/5915513668763648 > > > > I've never understood why some distros do something that stupid. They > > even prevent some people from setting up a backup server in emergency. > > > > So does this mean we'll drop this one ? > > For what it's worth, after EOL, data is moved to CentOS vault: > > https://vault.centos.org/6.10/ Thanks Adis. Not sure what this implies for setup scripts, but it's good to know. Willy
Re: do we want to keep CentOS 6 builds?
On 12/2/20 9:45 PM, Willy Tarreau wrote: On Wed, Dec 02, 2020 at 10:19:47PM +0500, ??? wrote: seems, CentOS 6 packages were removed from mirrors https://cirrus-ci.com/task/5915513668763648 I've never understood why some distros do something that stupid. They even prevent some people from setting up a backup server in emergency. So does this mean we'll drop this one ? For what it's worth, after EOL, data is moved to CentOS vault: https://vault.centos.org/6.10/ Best regards, -- Adis Nezirovic Software Engineer HAProxy Technologies - Powering your uptime! 375 Totten Pond Road, Suite 302 | Waltham, MA 02451, US +1 (844) 222-4340 | https://www.haproxy.com
Re: do we want to keep CentOS 6 builds?
On Wed, Dec 02, 2020 at 10:19:47PM +0500, ??? wrote: > seems, CentOS 6 packages were removed from mirrors > > https://cirrus-ci.com/task/5915513668763648 I've never understood why some distros do something that stupid. They even prevent some people from setting up a backup server in emergency. So does this mean we'll drop this one ? Willy
Re: do we want to keep CentOS 6 builds?
seems, CentOS 6 packages were removed from mirrors https://cirrus-ci.com/task/5915513668763648 вт, 17 нояб. 2020 г. в 20:28, Willy Tarreau : > On Tue, Nov 17, 2020 at 02:50:52PM +0100, William Lallemand wrote: > > I agree with that, however the problem will be the test of features that > > require an up to date version of OpenSSL, maybe we should improve the > > script so we could at least exclude non-openssl and non-1.1.1 versions. > > This is a good point, and actually this currently is causing me test > failures on my home PC, that I've learned to ignore for the same reason > (openssl 1.0.2). This would also help with the myriad of openssl ersatz > out there. > > > > By the way, RHEL6/CentOS6 are not the only ones affected by the OpenSSL > > > 1.0.2 maintenance mess, there's Ubuntu 16.04 as well, which gets > regular > > > maintenance till April 2021 and extended maintenance till April 2024. > > > And yes, I do want to see older versions of openssl continue to work as > > > long as it doesn't come with too high a maintenance cost. > > > > > It looks worse with CentOS, it uses a 1.0.1 release :-) > > Ah, there's also Ubuntu 14 in this situation apparently, which is still > under extended maintenance till April 2022. However I doubt anyone uses > it for that long. > > If you remember, RHEL7/CentOS7 were released with 1.0.1, and had to upgrade > mid-way to 1.0.2 due to the pressure of everyone asking for ALPN support. > I'm reading that EL7 should stay on 1.0.2 for a while due to the ABI/API > compatibility issues between 1.0.2 and 1.1.x (not surprising): > > https://access.redhat.com/solutions/2728111 > > That's one more reason for properly supporting 1.0.2 then! > > Willy >
Re: do we want to keep CentOS 6 builds?
On Tue, Nov 17, 2020 at 02:50:52PM +0100, William Lallemand wrote: > I agree with that, however the problem will be the test of features that > require an up to date version of OpenSSL, maybe we should improve the > script so we could at least exclude non-openssl and non-1.1.1 versions. This is a good point, and actually this currently is causing me test failures on my home PC, that I've learned to ignore for the same reason (openssl 1.0.2). This would also help with the myriad of openssl ersatz out there. > > By the way, RHEL6/CentOS6 are not the only ones affected by the OpenSSL > > 1.0.2 maintenance mess, there's Ubuntu 16.04 as well, which gets regular > > maintenance till April 2021 and extended maintenance till April 2024. > > And yes, I do want to see older versions of openssl continue to work as > > long as it doesn't come with too high a maintenance cost. > > > It looks worse with CentOS, it uses a 1.0.1 release :-) Ah, there's also Ubuntu 14 in this situation apparently, which is still under extended maintenance till April 2022. However I doubt anyone uses it for that long. If you remember, RHEL7/CentOS7 were released with 1.0.1, and had to upgrade mid-way to 1.0.2 due to the pressure of everyone asking for ALPN support. I'm reading that EL7 should stay on 1.0.2 for a while due to the ABI/API compatibility issues between 1.0.2 and 1.1.x (not surprising): https://access.redhat.com/solutions/2728111 That's one more reason for properly supporting 1.0.2 then! Willy
Re: do we want to keep CentOS 6 builds?
вт, 17 нояб. 2020 г. в 18:51, William Lallemand : > On Tue, Nov 17, 2020 at 12:16:05PM +0100, Willy Tarreau wrote: > > Hi all, > > > > On Tue, Nov 17, 2020 at 12:10:41AM +0100, Lukas Tribus wrote: > > > No, but since we *only test* master, this is the only way we get > > > *some* coverage for the changes we are backporting to stable branches. > > > After all, a large percentage of them come from master. How do we know > > > that a fix that we are backporting to 1.8 won't break the build on an > > > older libc or gcc? There is a chance that this would have failed a > > > test on master. > > > > I agree with the goal here. This is the same reason I occasionally > > run a build on an old AIX 5.2 system I have access to. I don't care > > if it works or not, I just want to see if I changed something without > > noticing. Many of the compiler optimization bugs for example can be > > triggered on older systems, the usual ctype bugs are revealed there as > > well, and many of the non-linux portability issues can be triggered on > > older libc as well. Trust me, I've been used to seeing haproxy being > > built on uncommon systems, and sometimes requiring a few tricks, but > > that's what people needed. > > > > > I am very sympathetic to drop support for old systems, *if the > > > maintenance overhead becomes a burden* - and I don't set this bar > > > high. > > > > Agreed. I'm in favor of no more than a few minutes a month if that > > still fits. When it becomes a pain (but then why?) we can drop it. > > I suggest however that we mark it as "allowed to fail" so that it's > > just indicative and we don't feel guilty not to address such issues > > quickly. > > > I agree with that, however the problem will be the test of features that > require an up to date version of OpenSSL, maybe we should improve the > script so we could at least exclude non-openssl and non-1.1.1 versions. > > > > So, is this about OpenSSL? > > > > By the way, RHEL6/CentOS6 are not the only ones affected by the OpenSSL > > 1.0.2 maintenance mess, there's Ubuntu 16.04 as well, which gets regular > > maintenance till April 2021 and extended maintenance till April 2024. > > And yes, I do want to see older versions of openssl continue to work as > > long as it doesn't come with too high a maintenance cost. > > > It looks worse with CentOS, it uses a 1.0.1 release :-) > let us think about it a bit. in theory we can drop older openssl if we want. I planned to write a guide "how to build and link haproxy against custom openssl" (it might help in many cases) or we can continue to run vanilla CentIS 6 builds. > > -- > William Lallemand >
Re: do we want to keep CentOS 6 builds?
On Tue, Nov 17, 2020 at 12:16:05PM +0100, Willy Tarreau wrote: > Hi all, > > On Tue, Nov 17, 2020 at 12:10:41AM +0100, Lukas Tribus wrote: > > No, but since we *only test* master, this is the only way we get > > *some* coverage for the changes we are backporting to stable branches. > > After all, a large percentage of them come from master. How do we know > > that a fix that we are backporting to 1.8 won't break the build on an > > older libc or gcc? There is a chance that this would have failed a > > test on master. > > I agree with the goal here. This is the same reason I occasionally > run a build on an old AIX 5.2 system I have access to. I don't care > if it works or not, I just want to see if I changed something without > noticing. Many of the compiler optimization bugs for example can be > triggered on older systems, the usual ctype bugs are revealed there as > well, and many of the non-linux portability issues can be triggered on > older libc as well. Trust me, I've been used to seeing haproxy being > built on uncommon systems, and sometimes requiring a few tricks, but > that's what people needed. > > > I am very sympathetic to drop support for old systems, *if the > > maintenance overhead becomes a burden* - and I don't set this bar > > high. > > Agreed. I'm in favor of no more than a few minutes a month if that > still fits. When it becomes a pain (but then why?) we can drop it. > I suggest however that we mark it as "allowed to fail" so that it's > just indicative and we don't feel guilty not to address such issues > quickly. I agree with that, however the problem will be the test of features that require an up to date version of OpenSSL, maybe we should improve the script so we could at least exclude non-openssl and non-1.1.1 versions. > > So, is this about OpenSSL? > > By the way, RHEL6/CentOS6 are not the only ones affected by the OpenSSL > 1.0.2 maintenance mess, there's Ubuntu 16.04 as well, which gets regular > maintenance till April 2021 and extended maintenance till April 2024. > And yes, I do want to see older versions of openssl continue to work as > long as it doesn't come with too high a maintenance cost. > It looks worse with CentOS, it uses a 1.0.1 release :-) -- William Lallemand
Re: do we want to keep CentOS 6 builds?
Hi all, On Tue, Nov 17, 2020 at 12:10:41AM +0100, Lukas Tribus wrote: > No, but since we *only test* master, this is the only way we get > *some* coverage for the changes we are backporting to stable branches. > After all, a large percentage of them come from master. How do we know > that a fix that we are backporting to 1.8 won't break the build on an > older libc or gcc? There is a chance that this would have failed a > test on master. I agree with the goal here. This is the same reason I occasionally run a build on an old AIX 5.2 system I have access to. I don't care if it works or not, I just want to see if I changed something without noticing. Many of the compiler optimization bugs for example can be triggered on older systems, the usual ctype bugs are revealed there as well, and many of the non-linux portability issues can be triggered on older libc as well. Trust me, I've been used to seeing haproxy being built on uncommon systems, and sometimes requiring a few tricks, but that's what people needed. > I am very sympathetic to drop support for old systems, *if the > maintenance overhead becomes a burden* - and I don't set this bar > high. Agreed. I'm in favor of no more than a few minutes a month if that still fits. When it becomes a pain (but then why?) we can drop it. I suggest however that we mark it as "allowed to fail" so that it's just indicative and we don't feel guilty not to address such issues quickly. > So, is this about OpenSSL? By the way, RHEL6/CentOS6 are not the only ones affected by the OpenSSL 1.0.2 maintenance mess, there's Ubuntu 16.04 as well, which gets regular maintenance till April 2021 and extended maintenance till April 2024. And yes, I do want to see older versions of openssl continue to work as long as it doesn't come with too high a maintenance cost. Just my two cents, Willy
Re: do we want to keep CentOS 6 builds?
Hello Ilya, On Mon, 16 Nov 2020 at 22:48, Илья Шипицин wrote: > we run CI only for master branch. Exactly! > do all those people want to run latest unstable haproxy on oldish RHEL 6 ? No, but since we *only test* master, this is the only way we get *some* coverage for the changes we are backporting to stable branches. After all, a large percentage of them come from master. How do we know that a fix that we are backporting to 1.8 won't break the build on an older libc or gcc? There is a chance that this would have failed a test on master. This is *NOT* about CentOs6 specifically. This is about having at least one old linux system we are testing with, so we don't break things that *we don't want to break*. How sure are you that there are no supported OS's out there that still use gcc 4.4 or glibc 2.12, which we are testing here "for free" and before backporting the fix to 1.8? I am very sympathetic to drop support for old systems, *if the maintenance overhead becomes a burden* - and I don't set this bar high. My only point is that we should be discussing the problem we are trying to solve (effort that goes into supporting and testing an obsolete system?). I don't know how much hand holding the tests require - I can't quantify the effort that goes into this, which is why I would like this discussion to be about that as opposed to bikesheed around EOL's. So, is this about OpenSSL? Thanks, Lukas
Re: do we want to keep CentOS 6 builds?
I mean, I certainly do. And today's unstable haproxy is tomorrow's stable haproxy... On Mon, Nov 16, 2020 at 1:48 PM Илья Шипицин wrote: > we run CI only for master branch. > > do all those people want to run latest unstable haproxy on oldish RHEL 6 ? > > пн, 16 нояб. 2020 г. в 23:56, James Brown : > >> Since CentOS 6 / RHEL 6 is the last pre-systemd release, I think there >> are lots of shops planning on keeping it around with various >> community-supported backports for years to come. I would vote to keep it >> around until it becomes an undue burden for CI, because there are still >> tons of EL6 users out there that have no migration path. >> >> On Sun, Nov 15, 2020 at 1:55 PM John Lauro wrote: >> >>> CentOS 6 isn't EOL until the end of the month, so there is a couple of >>> more weeks left. >>> >>> There is at least one place to pay for support through 2024. >>> ($3/month/server) >>> >>> Might be good to keep for a a bit past EOL, as I know when migrating >>> services sometimes I'll throw a proxy server on the old server to the new >>> one... and there will likely be some that don't make the Nov 30th deadline >>> to retire all Centos 6 servers. >>> >>> >>> On Sun, Nov 15, 2020 at 11:15 AM Илья Шипицин >>> wrote: >>> Hello, we still run cirrus-ci builds. CentOS 6 is EOL. should we drop it? Ilya >>> >> >> -- >> James Brown >> Engineer >> > -- James Brown Engineer
Re: do we want to keep CentOS 6 builds?
we run CI only for master branch. do all those people want to run latest unstable haproxy on oldish RHEL 6 ? пн, 16 нояб. 2020 г. в 23:56, James Brown : > Since CentOS 6 / RHEL 6 is the last pre-systemd release, I think there are > lots of shops planning on keeping it around with various > community-supported backports for years to come. I would vote to keep it > around until it becomes an undue burden for CI, because there are still > tons of EL6 users out there that have no migration path. > > On Sun, Nov 15, 2020 at 1:55 PM John Lauro wrote: > >> CentOS 6 isn't EOL until the end of the month, so there is a couple of >> more weeks left. >> >> There is at least one place to pay for support through 2024. >> ($3/month/server) >> >> Might be good to keep for a a bit past EOL, as I know when migrating >> services sometimes I'll throw a proxy server on the old server to the new >> one... and there will likely be some that don't make the Nov 30th deadline >> to retire all Centos 6 servers. >> >> >> On Sun, Nov 15, 2020 at 11:15 AM Илья Шипицин >> wrote: >> >>> Hello, >>> >>> we still run cirrus-ci builds. >>> CentOS 6 is EOL. >>> >>> should we drop it? >>> >>> Ilya >>> >> > > -- > James Brown > Engineer >
Re: do we want to keep CentOS 6 builds?
Since CentOS 6 / RHEL 6 is the last pre-systemd release, I think there are lots of shops planning on keeping it around with various community-supported backports for years to come. I would vote to keep it around until it becomes an undue burden for CI, because there are still tons of EL6 users out there that have no migration path. On Sun, Nov 15, 2020 at 1:55 PM John Lauro wrote: > CentOS 6 isn't EOL until the end of the month, so there is a couple of > more weeks left. > > There is at least one place to pay for support through 2024. > ($3/month/server) > > Might be good to keep for a a bit past EOL, as I know when migrating > services sometimes I'll throw a proxy server on the old server to the new > one... and there will likely be some that don't make the Nov 30th deadline > to retire all Centos 6 servers. > > > On Sun, Nov 15, 2020 at 11:15 AM Илья Шипицин > wrote: > >> Hello, >> >> we still run cirrus-ci builds. >> CentOS 6 is EOL. >> >> should we drop it? >> >> Ilya >> > -- James Brown Engineer
Re: do we want to keep CentOS 6 builds?
CentOS 6 isn't EOL until the end of the month, so there is a couple of more weeks left. There is at least one place to pay for support through 2024. ($3/month/server) Might be good to keep for a a bit past EOL, as I know when migrating services sometimes I'll throw a proxy server on the old server to the new one... and there will likely be some that don't make the Nov 30th deadline to retire all Centos 6 servers. On Sun, Nov 15, 2020 at 11:15 AM Илья Шипицин wrote: > Hello, > > we still run cirrus-ci builds. > CentOS 6 is EOL. > > should we drop it? > > Ilya >
Re: do we want to keep CentOS 6 builds?
Hello, On Sun, 15 Nov 2020 at 17:14, Илья Шипицин wrote: > > Hello, > > we still run cirrus-ci builds. > CentOS 6 is EOL. > > should we drop it? I think CentOs6 gives us good feedback about older operating systems that we may not necessarily want to break. The question for me is not so much whether we want to test with CentOs 6, it's more about do we want to be aware and fix build issues with those old systems? If the answer to the latter is yes, then we should keep the tests. If the answer is no, then we should drop them of course. How much of a burden is it to a) keep testing and b) keep supporting (by making sure it builds) on old kernels, libc and libraries? I don't have a strong opinion, but I would tend to keep the support (even though it's EOL). However if this is a continued pain in the ass, for example with openssl, then it's probably better to drop it. Lukas
Re: do we want to keep CentOS 6 builds?
Ilya, Am 15.11.20 um 17:14 schrieb Илья Шипицин: > we still run cirrus-ci builds. > CentOS 6 is EOL. > > should we drop it? > If it's EOL and they did not upgrade the OS then they are either lazy or interesting in "stability". Either way they are probably not going to upgrade HAProxy any further. I'd say that keeping the CentOS 6 builds is a waste of effort. Especially since they are limiting us with regard to the supported SSL version from my understanding (I might be wrong there, but I believe this is what https://github.com/haproxy/haproxy/issues/944 is about). Best regards Tim Düsterhus
do we want to keep CentOS 6 builds?
Hello, we still run cirrus-ci builds. CentOS 6 is EOL. should we drop it? Ilya
