Hi Malcolm, Hi Willy, after a bit of a hiatus I'd like to restart this discussion.
On Mon, Dec 24, 2012 at 10:23:15AM +0100, Willy Tarreau wrote: > Hi Malcolm, > > On Mon, Dec 24, 2012 at 09:06:25AM +0000, Malcolm Turnbull wrote: > > Willy / Simon, > > > > I'm very happy to add a down option, my original thought was that you > > would use the standard health checks as well as the dynamic agent for > > changing the weight. > > That's what I thought I initially understood from our discussion a few > months ago but then your post of the specs last week slightly confused > me as I understood you needed this as a dedicated check. I think it was > the same for Simon. Sorry, I think that the problem here lies in my understanding of what is desired. > > As you may for example want a specific HAproxy SMTP health check + use > > the dynamic weighting agent. > > Exactly. But then we have two options : > - retrieve the information from the checked port (easy for HTTP or TCP) > - retrieve the information from a dedicated port => this involves a > second task to do this, with its own check intervals. > > The latter doesn't seem stupid at all, quite the opposite in fact, but > it will require more settings on the server line. However it comes with > a benefit, it is that when the agent returns "disable", checks are > disabled on the real port, but then we could have the agent continue to > be checked and later return a valid result again. > > > I'm not sure if that would cause some coding issues if the health > > checks say 'Down' and the agent says 50%? (I would assume haproxy > > health checks take priority?) > > Status and weights are orthogonal. The real check should have precedence. > > > Or if the agent says Down but the HAProxy health check says up? > > I think it should be ANDed. This could help provide a first implementation > of multi-port checks after all. That sounds reasonable. > > I've certainly happy for Down to be added as an option with a > > description string. > > Also I'm assuming that later (the dynamic agent) could easily be > > extended to an http style get check rather than TCP (lb-agent-chk) if > > users prefer to write an HTTP server application to integrate with it > > (Kemp and Barracuda support this method). On the topic of of down. I think that Willy's proposal is entirely reasonable. However its unclear to me if disable should also be supported or not. > That's what I'm commonly observing too. Even right now, there are a lot > of users who use httpchk for services that are not HTTP at all, but they > have a very simple agent responding to checks. > > So now we have to decide what to do. I think Simon's code already provides > some useful features (assuming we support "down"). It should probably be > extended later to support combined checks. > > In my opinion, this could be done in three steps : > > 1) we merge Simon's work with the "option lb-agent-chk" directive which > *replaces* the health check method with this one ; > > 2) we implement "agent-port" and "agent-interval" on the server lines to > automatically enable the agent to be run on another port even when a > different check is running ; > > 3) we implement "http-check agent-hdr <name>" to retrieve the agent string > from an HTTP header for HTTP checks ; > > That way we always support exactly the same syntax but can retrieve the > required information at different places depending on the checks. Does > that sound good to you ? That sounds entirely reasonable to me.
