[squid-dev] [RFC\PREVIEW] ICAP service nodown option addition.

[Alex Rousskov]

On 01/09/2016 12:35 PM, Eliezer Croitoru wrote:
> On 08/01/2016 17:27, Alex Rousskov wrote:
>> 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.

> Both nodown and always-up do not describe the exact meaning of the flag.
> Do you(..and others) think that a longer name would be better? something
> like "options-only-suspened" or "suspend-only-by-options-fail" ?

Let's finalize the scope of the changes before deciding how to name
them. My comment above was specific to the "negativity" of the name you
have chosen. The negativity should be avoided regardless of the feature
scope. As for the scope of the changes, I continue to think that a
different solution is needed.


> I was thinking about it but this feature eliminates every suspension
> between each OPTIONS fetch\check.

IMO, the need for "eliminating suspension between OPTIONS" should be
addressed by adding an adaptation_failure directive driven by ACLs
instead of adding optional hard-coded decision logic. For example,

  # "allowed" adaptation failures are not counted as service failures
  adaptation_failure allow all


> I know it doesn't fit all setups but ...

Being applicable to "all setups" is impossible and is not required for
an optional feature to be accepted. However, while your specific use
case is important, we ought to consider other use cases as well,
especially when adding new configuration options.

The adaptation_failure directive will address a lot more use cases,
including yours. It is not difficult to implement. Thus, if we add
something, we should add the more general adaptation_failure (or
similar) support and not nodown (or similar) support.


> the idea is that the service is essential and the proxy cannot allow any
> traffic without this service 

Also known as the default bypass=0 setting combined with the "send all
requests to this service" adaptation_access rule. This is already fully
supported. What Squid does not yet support is an admin-configurable
classification of adaptation failures: Which adaptation failures are
specific to the adaptation transaction and which are a sign of a failing
adaptation service? Your "nodown" proposal classifies all adaptation
failures as non-service failures. We can do much better without a lot
more work.


> Do you think a wiki article will be good enough to explain the use cases
> of this option instead of the documentation?

I think we need a different configuration option or two. I do not think
the right new options require extensive documentation on the wiki, but
describing your specific use case and how you have handled it using
those new options may be useful for many admins, of course.


HTH,

Alex.