On Thu, May 28, 2020 at 02:26:50PM +0200, Willy Tarreau wrote:
> 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.
That would be confusing I think, because if you show +/- in the
dump, when looking at it you will suppose that every options are there.
For example, if we follow this reasoning, if you have an openssl with
OPENSSL_NO_OCSP, you can't display "-SSL_OCSP" because the support was
not built in haproxy since it requires to link with an ocsp function.
> 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.
>
Well, it could be haproxy -vvv, It doesn't bother me if it's in -vv
either honestly. Look at vim for example, vim --version gives you every
feature activated or not. But I agree that is should be on a new line,
because they are inherited options, not build one activated on build.
> 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.
>
I agree, could be a good idea.
--
William Lallemand
