Squid3 and multiple ICAP services

Hi there,

        Handling of multiple ICAP services in Squid3 does not match squid.conf
expectations well. Here is a brief summary of the current state, with
Squid2 comparison:

load balancing (using similar services in a round-robin):
  Squid2: via multiple identically named icap_service options
  Squid3: not documented and not supported.

backup (using another service when a similar service is down):
  Squid2: via multiple identically named icap_service options
  Squid3: not documented but supported via icap_class option

chaining (applying one service after another):
  Squid2: via icap_class option
  Squid3: semi-documented but not supported

I believe that using multiple identically named icap_service options is
a bad interface. Each service should have its own name for configuration
clarity, reporting, debugging, and such.

The way chaining is explained in squid3.conf will confuse many users.
The name of the option (icap_class) does not imply chaining either. Many
users will think that icap_class is about backup, not chaining. In fact,
the original Squid3 implementation was using icap_class for something
resembling backup, not chaining.

I would like to polish this for Squid3 STABLE release, but since my
proposal requires changing squid.conf option names, I do not want to do
it without your feedback. Here is what I would like to do:

service naming:
  Each service must have a unique name.

load balancing and backup:
  Add icap_service_set option. Services (or service chains) listed under
this option are load balanced and "down" entries are skipped.

chaining:
  Rename icap_class into icap_service_chain option. Services (or service
sets) listed under this option are applied one after another.

Any objections or better ideas?

Thank you,

Alex.
P.S. I am not going to implement load balancing and chaining in Squid3
until somebody needs it enough, but the configuration will be cleaned up
and ready for that implementation. The backup code is already done.
Received on Wed Oct 25 2006 - 17:42:28 MDT