Thanks for your reply Willy > I think that for your current needs, we'd need at least a "check-name" > directive on the servers to force the server name, which would default > to the server's name in the configuration, and which would automatically > be sent along with the Host header if some http-check directive is set > (eg: "http-check set-host" with no argument).
The 'info' parameter in the server directive serves this purpose for me. I left it to the user to specify any "identifying" information that would enable the external server to identify the host to be health checked. I came about this largely due to a quirk in the existing implementation of health checks (1.4 version in production) that we use. When using the form below option httpchk <method> <uri> <version> you can specify for the version field HTTP\ 1.1\r\nHost: myhost.com\r\nX-Custom-Header: blah we have used this feature/quirk to specify a common host header for all servers. The servers do not respond to health checks in the absence of a specific Host header. I would not be surprised if others have noticed this behavior and likewise exploited it, leading me to present an option to configure an "info" header name. There is no limitation on using Host as the header name with the info parameter, but we may not do the same. > In my opinion, we'd have to cover the ability to perform multiple requests > to a server, by forcing or not an address (eg: http-check connect), by > passing headers with a value from the server, or by passing raw headers, > by passing cookies from responses to requests when using the same host > header (useful to authenticate to a server), and possibly some other stuff. Broadly I did this change as I did, to have haproxy only speak http for health checking and leaving it to a external system to do the health check. Looking ahead the external health checking implementation in my environment will query infrastructure specific information from Collins i.e. information that is not captured in any request/response from/to haproxy. Having haproxy do health checks using an external http server seemed like a viable option as it leaves me with flexibility to implement a custom health check. > I don't think this is something we should merge before 1.5-final, but > I do think that we'll quickly be able to test it in 1.6-dev and get > enough feedback so that at one point if we trust the feature enough > and it requires few changes, we'll be able to backport it into 1.5. No worries, we can certainly proceed with this patch while a more encompassing solution is implement. -Bhaskar On Fri, Feb 7, 2014 at 7:08 PM, Willy Tarreau <[email protected]> wrote: > Hi Bhaskar, > > On Fri, Feb 07, 2014 at 06:33:10PM -0500, Bhaskar Maddala wrote: >> Hello, >> >> I apologize for my persistence and realize that everyone if busy with >> getting >> 1.5 out of the door. I have no expectations on that front for the patch >> included >> here. However any feedback is welcome. I went thru some of the submitted >> patches and saw one by Simon Horman to use an external process after I >> made this change and will revisit that again. >> >> I re-did my implementation, and this time I am submitting it as a patch for >> consideration. I am posting the commit message that explains the change. > > This is interesting. Today we had a discussion with Baptiste about how to > make http checks work more like tcp checks (ie: have sequences of multiple > checks) and we first spotted the need to be able to specify *some* common > information (eg: some headers, etc) and some server-specific information. > > So between what you proposed and this discussion, we're starting to see > some pieces that start to make the puzzle. > > In my opinion, we'd have to cover the ability to perform multiple requests > to a server, by forcing or not an address (eg: http-check connect), by > passing headers with a value from the server, or by passing raw headers, > by passing cookies from responses to requests when using the same host > header (useful to authenticate to a server), and possibly some other stuff. > > I think it's too early to decide on an implementation, but we could possibly > first try to define a roadmap so that once we know what we want for the long > term, we can start with a subset which will remain compatible with future > versions (for example we don't need to support cookies right now). > > I think that for your current needs, we'd need at least a "check-name" > directive on the servers to force the server name, which would default > to the server's name in the configuration, and which would automatically > be sent along with the Host header if some http-check directive is set > (eg: "http-check set-host" with no argument). > > The other http-check rules were made to be reusable, and I think they > will be. We just need to complete them. > > I don't think this is something we should merge before 1.5-final, but > I do think that we'll quickly be able to test it in 1.6-dev and get > enough feedback so that at one point if we trust the feature enough > and it requires few changes, we'll be able to backport it into 1.5. > > > >> >> ================================================================= >> We add new directives to the http-check keyword >> >> The server option is used to specify an external >> health checking server to use for health checks. >> >> Example: >> http-check server <ipv4|ipv6> > > Please take a look at the "tcp-check connect" directive in the most > recent snapshot. By default it just connects. You can specify a port > (reusing the server's address) and we'll soon support an address. If > the directive is not there, the check is sent to normal server's > addr:port. We should try to standardize these things as much as > possible so that people don't confuse them as we do between tcp-request > and http-request which don't use the exact same actions for the same > things (eg: deny vs reject). > > I'm even wondering whether we should not use a special "send" directive > for http-check to indicate when to send versus when to prepare things. > But that could be a bit awkward and confusing. Just thinking loud... > > Cheers, > Willy >
