On Wed, 23 Sep 2015 09:37:41 +0200
Willy Tarreau <[email protected]> wrote:

> On Tue, Sep 22, 2015 at 10:18:10PM -0400, Michael Ezzell wrote:
> > I don't see a significant problem, if there are benefits to be gained.
> > 
> > I assume part of the motivation is to prevent inadvertently calling an
> > inappropriate function as an action, to perhaps to allow earlier validation
> > of the configuration of actions referencing Lua functions, and to separate
> > the namespaces of Lua functions and HAProxy Lua actions.
> 
> I'm seeing the same benefit. In fact I even *thought* that actions were
> registered like fetch/convs. But the current state of affairs now scares
> me for the future because indeed we don't want to call random functions
> by accident. Also, I don't know if some functions are shipped with Lua,
> but it could be painful if a new version of Lua brings new functions
> which collide with ones that people use in their configs. With a
> registration mechanism this cannot happen at all, so it's much safer.
> 
> It will also allow to use a wider character set in action names (eg: '-'
> or '.' that we use in the core config language). So all in all I think it's
> a good idea that's worth being done *before* the actual release otherwise
> we could regret it later.
> 
> Thierry, what's the impact of such a change (in terms of complexity, amount
> of code changed, risks of regressions, etc) ? I've found the issues I've been
> debugging since last week-end, they're fixed on paper now, I just need to fix
> the code and I'm thinking about issuing dev6 with all the pending fixes and
> having an extra dev7 next week before -final. Do you think such a change
> could be ready for dev6 so that people don't have to wait an extra week to
> test a change ?


The pending "use-service" code already embbed some changes in the
généric actions, like requirement of opaque data. So the change is easy
and the risk of regressions is low. In fact, the main complicated code
in the Lua is the runtime code and not the configuration parser nor
the registration of functions.

Thierry

Reply via email to