Hello Willy,

On Tue, Oct 22, 2019 at 04:46:43PM +0200, Willy Tarreau wrote:
> To be honest, I'm quite embarrassed by such a change. I think the main
> reason for the initial warning instead of error was that most people
> using haproxy in unprivileged environments never knew what to use as
> a ulimit-n or maxconn value, they only needed something that worked
> fine for small traffic. That's also how developers use it by the way,
> each time I start a config with explicit settings, I receive this warning
> and it allows me to test it anyway. My concern is that this will cause a
> large number of deployed system to simply stop working.
> On the other hand, we do have automatic settings now (at least for the
> FD) so it is easier for such users to simply drop the maxconn line and
> be fine with it.
> Probably that a good approach would be to have a new directive (or set
> of directives) such as "strict-limits" which would indicate if we need
> to warn or fail. We could then decide to let it warn by default and
> change it to strict mode by default later. Leaving at least one round
> of LTS with a warning indicating that this needs to be fixed or it will
> fail in the next version will be OK. This basically means keeping the
> default to relaxed until 2.2 and make it strict by default in 2.3.
> I suspect that we should set the memory behavior separately, but at
> the same time I don't recall having ever seen this one. Thus maybe we
> could already make it strict by default.
> Anyway I think you get the general point, warn users first that it will
> break next time, then break by default. It will leave them with enough
> time to fix their config or report their constraints.
> Just let me know if that's a good enough plan for you.

Thanks for the answer.
that's sounds good, let me come up with a new version of the patch.


Reply via email to