On Thu, May 28, 2020 at 01:30:56PM +0200, William Lallemand wrote:
> On Thu, May 28, 2020 at 03:39:50PM +0500, ???? ??????? wrote:
> > 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)
>
> Also, some features in SSL could be enabled only by rebuilding HAProxy,
> so it can be kind of confusing if you have the right openssl lib with
> this feature, but without the feature activated in haproxy. It's 3not a
> common case but it could happen. For example few days ago we rebuilt an
> OpenSSL version with SSLv3 support, but without rebuilding haproxy. So
> haproxy -vv wasn't showing the SSLv3 feature. But if you disable
> something else, let's say OCSP for example, you won't be able to see it
> in haproxy -vv.
I'm seeing other benefits of adopting a feature-based model. One of
them is that we could report them based not only on what was enabled,
but the real usability status which involves haproxy, the system and
the libraries. For example we could report "+0RTT" to indicate that
0RTT is enabled and supposed to work or "-TFO" to indicate that TFO
was built in but was detected as non-functional (e.g. OS limitation).
The pollers could be reported there as well.
Just as what we currently have to register build options using
hap_register_build_opts(), we could have another one to register a
simple word representing a feature with a boolean to indicate the
working status, and an equivalent of REGISTER_BUILD_OPTS() to make
them always available (useful inside #ifdefs). This could become
really nice 1) to take into account library variants at build time,
and 2) to mention the availability of certain new features that some
could want to backport later. For example we've had some VTCs which
couldn't be backported recently because they were using the new
"http-after-response" rules, though if a user backports them for his
own use, it makes sense to report that it's available.
However I think we'd rather report such features in a different
output from haproxy -vv, which was still made for the end user. Here
we're now talking about a technical output. I'd be fine with a line
such as "extra-features" which lists the stuff that's not necessarily
the base for a given version though, in order to easily spot backports
or optional stuff.
That even makes me think that a register line could look like this:
hap_register_feature(name, base_version, status);
where:
- name is the feature name ("SSL_ALPN", "HTTP_AFTER_RESPONSE", ...)
- base_version is the haproxy base version expected to expose that
feature (eg "2.2") resulting in all earlier versions to report it
on the line of "-vv". This will be particularly nice during
development because all features added before the final release
will appear there, and this can be particularly helpful in issue
reports
And with the full dump, the whole list of features (and their base
version) would be listed, which shows backports and also helps admins
figure that the feature they're relying on is fresh new and will
possibly not be usable if they have to roll back to a previous version.
This should still remain a bit limited so that we don't spend our time
registering features for each and every new option. Possibly that the
main driver for this should remain VTC first, and we'll see how that
evolves.
I'm not suggesting we go down that route immediately, that's just food
for a possibly durable design. Maybe as a first step we should at least
plan for a dedicated command line option to list them all and implement
very basic registration (without target version) as mentioned above.
Just my two cents,
Willy
