Hi Lukas,
On Tue, Oct 06, 2026 at 06:13:18PM +0000, Lukas Tribus wrote:
> Commit 7b01a8dbdd("MINOR: global: define diagnostic mode of execution")
> in 2.4-dev15 introduced diagnostic mode for config warnings.
>
> It was initially designed to be ignored by "zero-warning" mode
> (-dW) and documented accordingly.
>
> Since commit ced4148401 ("BUG/MINOR: diag: always show the version
> before dumping a diag warning") in 3.0-dev3 this changed, and
> zero-warning mode combined with diagnostic messages stop haproxy from
> starting. This appears to be a unintended consequence in ced4148401.
>
> I suggest we respect "zero-warning" mode, which is an opt-in choice an
> administrator consciously makes and stop haproxy from starting when
> diagnostic messages are emitted in zero-warning mode.
I really feel hesitant on this one. I didn't notice that we broke this
but the intent of the diag mode is not to emit real warnings but doubts
and suggestions. The config is supposed to work fine but the user's
awareness is raised on specific points to ensure they are intentional
and not the result of a failed copy-paste (the duplicate server cookie
being one example). I would like to be sure that at no point we refrain
from adding more such detections because they could cause trouble to
existing deployments. On the other hand, -dD was not initially meant to
be used in production but rather as a diagnostic tool (i.e. manually).
I don't know if users started to enable that by default in order to see
extra info on startup.
Thus as a rule of thumb I'd say that:
- if people use it by default, we should not count them in warnings
that can trigger a boot failure, and they shouldn't be counted as
boot warnings either as reported in stats (they're currently not);
- if users continue to use it only for diagnostics (i.e. check a
config before deploying), then I feel less of a problem with
counting them as that might ease some check scripts which want
to detect if anything is reported.
In the later case we could imagine starting the config first with -c -dW,
and if it passes, try it again with -c -dD -dW, and if it fails, report
the output as diagnostics worth being checked.
Maybe if we figure that there are distinct use cases (I don't think so
but I could be surprised), we could then extend -dW to take a level and
decide what to block on. But I'm really not fond at all of refusing to
start for what is being detected by -dD if users start to enable it by
default at boot. It was essentially meant for use with -c.
And yes I understand that we have a bug and we're trying to fix the
doc to match the current state caused by that bug. I don't know if
you or anyone else has opinions on the points above. At least mine as
a developer is that I want to continue to be able to freely add new
extended diags that don't break valid setups.
thanks,
Willy
