> The second style is needed in cases where we plan to do some maintanence
> activity on an upstream server and want to proactively not send traffic
> to it. Typical example is when you want to push new software, check with
> a couple of requests and see if your app is behaving well and if all
> looks fine, direct traffic to it.

Actually, you don't need health-checks for that, ngx_supervisord provides
that functionality out-of-the-box. If you plan on taking servers down for
maintenance, you can use supervisord_stop and supervisord_start handlers.
Please take a look at example configuration #2, because it does exactly
that:
http://labs.frickle.com/nginx_ngx_supervisord/README

> In the absence of priority between the two styles of checking, we could
> end up with a flapping upstream status. The logical priority seems to be
> that #2 wins over #1. So, if the health check url says an upstream
> server is down, no traffic should be sent it way and the health status
> evaluation based on style #1 should be ignored. If the health check
> deems and upstream to be up, then the outcome of #1 is the final status.

In-line checks are considered failures. When you take down server with
ngx_supervisord, it's marked down (same way as if you would add "down" in
your configuration and reload nginx), so it takes priority.

> I will not have time before this weekend to get started on merging
> these; so if someone gets down to doing it earlier, thanks :-)

I'll try to find some time today, can't promise anything though.

Best regards,
Piotr Sikora < piotr.sikora@frickle.com >



_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx