Hi,
I quite like not to reload haproxy every here and there (stats and
races..) and make
quite some use of 'acl foo .. -f aclfile'.
Now feature-creep mounts and aclfile shall be build/extended "on demand"
(think of something along fail2ban).
Besides losing stats, that can grow into a problem if multiple events
within very short times start to reload haproxy.
Following problems with rereading aclfile automatically by haproxy come
to mind:
- doing it for every request: disk IO killer
- doing it at fixed intervals: might no suite for "every" use-case (and
if many aclfiles around, disk IO again)
- passing an option per acl line likely be a parser hell
- more exotic foobars
My modest proposal would go like that - for starters :) :
- (global) option 'timeout aclfiles 300': will reload "special" aclfile
every 300s
- aclfile introduced by -F (instead -f) will flag it as "special"
which leaves a somewhat race when the special file is written while the
reload happens.
Maybe better: as above, but plus:
- a flagfile like aclfile.RELOAD has to be present at the 300s mark
Or, in a totally different approach, do what OpenBSD's pf(4) can do,
have a "table" that can be
manipulated via admin-socket.
Thoughts about it?
--
pb
