On Mar 02, Piotr Sikora wrote:
>> 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

The only philosophical objection I have to this style is having
something to do on the LB servers to change and upstream status. I
wanted a facility wherein something can be done on the upstream server
(rm the health check file) to remove it out of service.

I come from a world wherein any sort of access on the LB servers is
tightly controlled and the people managing the upstreams (application
servers) can plan a maintanence without ever involving the LB folks.

Am also not a fan of the supervisord_start/supervisord_stop directives
since managing the security aspects of it becomes a hassle.

I am however a fan of supervisord_inherit_backend_status which is why I
wanted to integrate it with the health-check plugin :-)

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