On Thu, Jan 09, 2020 at 08:22:29PM +0100, Tim Düsterhus wrote:
> Bob,
> Am 09.01.20 um 19:44 schrieb Zakharychev, Bob:
> > I'd say that since the issue can be solved naturally and completely within 
> > the confines of Lua itself, new parameters should not be introduced in 
> > HAProxy to give one ability to solve it differently while obscuring the 
> > solution in configuration of the host program, however tempting this might 
> > look. 
> To put my POV into a different perspective: HAProxy is the host program
> of the Lua scripts and thus it is responsible for providing a working
> environment to the script. It should not need to know how the file
> system layout works.
> Configuring this environment within HAProxy just feels natural even if
> it might be possible to configure this setting from within a dedicated
> "configuration script" as well.

The useful point I'm seeing here is that it allows users to use some
external Lua programs with no modification and only specify the paths
in the global section which centralizes everything specific to the
deployment. Also it even allows to use environment variables there,
which can be quite useful.

However, Bob, your concern confirms mine about the risks involved by
adding the ability to execute some Lua code inlined directly from the
haproxy config. So I think that if we want to stay reasonable, at least
for a while, we should take Tim's patch as it is now to help configure
the path, but not put Lua code in the config file.


Reply via email to