чт, 28 мая 2020 г. в 14:35, William Lallemand <[email protected]>:
> 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 > "require features" is something that will come with openssl 3.0, there will be no version anymore. anyway, I can install for example openssl-1.1.0 without APLN support. version is not very good indicator (and we try to use features in ifdef wherever possible) as for current failures, as a short term solution, I think we can merge patch and figure out "feature" approach later. > > -- > William Lallemand >
