[squid-dev] [RFC\PREVIEW] ICAP service nodown option addition.
Alex Rousskov
rousskov at measurement-factory.com
Fri Jan 8 15:27:13 UTC 2016
On 01/07/2016 07:03 PM, Eliezer Croitoru wrote:
> I added a configurable option to the ICAP services named "nodown" but
> maybe another name would be better fit.
Please do not use negative option names. If this feature is committed
despite my objections, please consider using "always-up" or another
positive name.
> The idea of the patch is to allow the admin to count on the periodic
> OPTIONS request only to identify the current state of the ICAP service.
If an ICAP OPTIONS request fails, will the service be marked as down? If
yes, the option name is misleading. If not, your description above is
misleading. If this feature is committed, please adjust the
documentation to clearly define whether Squid may mark a nodown=1
service as down for any reason.
> I was thinking about using the icap_service_failure_limit with a very
> high limit but it is an ICAP global configuration and not a service
> specific configuration.
IMO, you should add a service-specific failure-limit option instead of
adding a brand new option with an overlapping but very narrow scope.
Squid already implements the failure-limit logic on a per-service basis.
You just need to add a per-service option (that will default to the
global one).
> + [...] It gives the
> + service admin to implement his own heart-beat script which
> + will work as a replacment to the default internal requests
> + success\failure probes while the ICAP service state is UP.
> + An external heart-beat script can run under external_acl
> + and can be checked in http_access and couple other acls
> + vectoring points.
IMO, this text should not be added to the new option because it talks
about controlling access to an ICAP service rather than about [not]
changing the service state which the new option controls. Referring to
adaptation_access from the new option documentation and adding a similar
hint to the adaptation_access documentation instead may be a good idea.
HTH,
Alex.
More information about the squid-dev
mailing list