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.

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

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

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 ?

Best regards,
Willy


Reply via email to