Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
MEDIUM: log: relax some checks and emit diag warnings instead in lf_e…
…xpr_postcheck() With 7a21c3a ("MAJOR: log: implement proper postparsing for logformat expressions") which finally made postparsing checks reliable, we started to get report from users that couldn't start haproxy 3.0 with configs that used to work in the past. The current situation is described in GH haproxy#2642. While the checks are mostly relevant, it turns out there are not strictly needed anymore from a technical point of view. Most of them were useful in early logformat implementation to prevent runtime bugs due to the use of an alias or fetch at runtime from an incompatible proxy. It's been a few versions already that the code handling fetches and log aliases is robust enough to support fetches/aliases used from the wrong context: all it does is that the fetch/alias will silently fail if it's not available. This can be proved by the fact that even if the postparsing checks were partially broken in the past, it didn't cause runtime issues (at least on recent haproxy versions). Most of these checks can now be seen as configuration hints: when a check triggers, it will indicate a configuration inconsistency in most cases, but they are some corner cases where it is not possible to know at config time if the conditions will be met for the alias/fetch to work properly.. so instead of failing with a hard error like we did so far, let's just be more permissive and report our findings using "diag_warning": such warnings are only emitted when haproxy is started with '-dD' cli option. We also took this opportunity to improve messages clarity and make them more precise (report the offending item instead of complaining about the whole expression because of a single element). With this patch, configs that used to start before 7a21c3a shouldn't trigger hard errors anymore. This may be backported in 3.0.
- Loading branch information