I agree as well.. :-). Our original specification was to match the way that ldirectord does its external health checks (so that the customer scripts are compatible). We could just change ldirectord to be compatible with the new style as it sounds more extensible (leaving it backwards compatible as well would be nice.)
On 15 August 2014 08:11, Simon Horman <ho...@verge.net.au> wrote: > [Cc Malcolm Turnbull] > > On Fri, Aug 15, 2014 at 12:29:36AM +0200, Willy Tarreau wrote: > > Hi Cyril! > > > > On Thu, Aug 14, 2014 at 10:30:52PM +0200, Cyril Bonté wrote: > > > Hi all, > > > > > > Le 07/08/2014 01:16, Cyril Bonté a écrit : > > > >Hi Bjoern, > > > > > > > >Le 06/08/2014 22:16, bjun...@gmail.com a écrit : > > > (...) > > > >>[ALERT] 216/205611 (1316) : Starting [be_test:node01] check: no > listener. > > > >>Segmentation fault (core dumped) > > > > > > > >OK, I could reproduce it. This is happening for several reasons : > > > >1. External checks can only be used in "listen" sections. > > > >This is not clearly documented but it can be guessed by the arguments > > > >passed to the command : the proxy address and port are required (see > [1]). > > > >I think this is annoying because it's only usable in some specific use > > > >cases. Maybe we should rework this part of the implementation : I see > > > >that for unix sockets, the port argument is set to "NOT_USED", we > could > > > >do the same for checks in a backend section. Willy, Simon, is it OK > for > > > >you ? > > > > > > After some thoughts, I'd like to suggest a new implementation. > > > > > > I tried to imagine in which use case sysadmins in my company would need > > > the first listener address/port of the proxy but I couldn't find one, > or > > > when I almost found one, other information could be more useful. > > > It's really too specific to be used by everyone, and I'm afraid it will > > > be error-prone in a configuration lifecycle. > > > Based from the current implementation, it imposes an artificial order > in > > > the bind list, which didn't exist before. If the external healthcheck > > > checks thoses values but someone modifies the bind order (by > > > adding/removing one, or because a automated script generates the > > > configuration without any guaranty on the order, ...), it will > > > mysteriously fail until someone remembers to re-read the healthcheck > script. > > > > > > Also, some years ago, I developed a tool which called external scripts > > > which were (supposed to be) simple with only 2-3 arguments. Over the > > > time, users wanted new arguments, some of them were optional, some > > > others not. After several years, some calls got nearly 20 arguments, I > > > let you imagine how a nightmare it is to maintain this. I fear this > will > > > happen to the haproxy external healthcheck (someone will want to > > > retrieve the backend name, someone else will want to retrieve the > > > current number of sessions, ...). > > > > > > So, I came to another solution : let's use environment variables > > > instead. This will permit to add new ones easily in the future. > > > > That's a really clever idea! > > > > > And currently, instead of providing the bind address/port, we could > pass > > > the backend name and id. > > > > > > For example, as a current minimal implementation : > > > - Backend variables > > > HAPROXY_BACKEND_NAME=my_backend > > > HAPROXY_BACKEND_ID=2 > > > - Server variables > > > HAPROXY_SERVER_ADDR=203.0.113.1 > > > HAPROXY_SERVER_PORT=80 > > > or maybe in a single variable, such as HAPROXY_SERVER=203.0.113.1:80 > > > > > > And if we still want to provide the listener address, why not adding > > > optional variables : > > > HAPROXY_BIND_ADDR=127.0.0.1 > > > HAPROXY_BIND_PORT=80 > > > or as the server address, we could use a single variable (HAPROXY_BIND) > > > > > > For an unix socket : > > > HAPROXY_BIND_ADDR=/path/to/haproxy.socket (without HAPROXY_BIND_PORT > > > variable) > > > > > > If we want to provide all the listeners, we can add a new environment > > > variable HAPROXY_BIND_COUNT=<number of listeners) > > > and list the listeners in environement variables suffixed by <n> where > > > <n> = [1..number of listeners]. > > > Example : > > > HAPROXY_BIND_COUNT=2 > > > HAPROXY_BIND_ADDR_1=127.0.0.1 > > > HAPROXY_BIND_PORT_1=80 > > > HAPROXY_BIND_ADDR_2=/path/to/haproxy.socket > > > > > > Any suggestion ? > > > If it's ok, I can work on a patch. > > > > I have to say I like it. It's by far much more extensible and will not > > require users to upgrade their scripts each time a new variable is added. > > I agree that is quite a clever idea, and I have no objections to it. > > However, I'd like to allow Malcolm Turnbull to comment as I wrote > the current code to meet his needs. > -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)330 1604540 http://www.loadbalancer.org/
