[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.
