On Thu, May 28, 2020 at 09:32:25AM +0200, Willy Tarreau wrote: > On Thu, May 28, 2020 at 12:21:20AM +0200, Tim Düsterhus wrote: > > Ilya, > > > > Am 27.05.20 um 22:53 schrieb ???? ???????: > > > Hello, > > > > > > let us skip new test on CentOS6 > > > > > > > There definitely should be a smarter solution than "delete test" to skip > > tests that depend on OpenSSL's features. > > Ideally we'd need to add a REQUIRE_OPENSSL_VERSION directive I think. > We'd make a special case of openssl but it simply matches the reality > which is that we have a very tight relation with it. I wouldn't be > surprized if in the future we also have to add a kernel version test > for certain advanced features. > > > Or maybe we should just get rid of CentOS 6 tests, it will be end of > > life on November, 30th anyway. > > It depends. Extended support is still valid for 4 more years, however > I can't imagine users running a newer haproxy version on that old a > system. Those relying on old systems just do that because they can't > afford to have moving pieces in mission critical deployments. They'd > definitely not upgrade haproxy on such a system! > > So yes, I think it can make sense to remove RHEL6 from the tests if > it's too much of a burden to maintain. Or maybe we can adopt Ilya's > workaround until 2.2 is released, and completely drop it afterwards ? > I'm against it, because it allows us to check if HAProxy still builds with old version of OpenSSL, even if they are not supported anymore, and even if no new features are available. HAProxy is an toolbox which is useful sometimes in old environments. People could use an old version of HAProxy, of course, but honestly it's not that painful to check if 0.9.8 still build.
In my opinion it's not Centos 6 the problem, but the fact that we don't check the features available in OpenSSL during the tests. And we will have more problems with that in the future if we use features available only in newer versions of OpenSSL. And we probably already remove manually some tests because of that. We could also have this problem with BoringSSL etc. What I'm seeing in the sourcecode is that we still have a lot of #ifdef with checks on the version and the library. Instead we could do a cleaner thing, set constants for SSL features depending on the lib and version, and checks these constants instead of the version in the code. The constant could then be reported like the build options in haproxy -vv, and use that in REQUIRE_OPTIONS or in a new variable like REQUIRE_FEATURES. For example we could have in the .vtc: REQUIRE_FEATURES=SSL_ALPN -- William Lallemand
