The reasons I would want them are in the original email, but here are some more details.
1. -- Gathering of unique stats without having to define a pool twice This would be stellar for adhoc debug. (how much traffic matches this ACL??), but also useful for general traffic classification. 2. -- Allowing a pool to be served by a backup pool if all of the original pool's servers are down. Our app tier machines are technically capable of serving /ANY/ content. (we have a common code deploy) However, we use HAproxy and header or URL matching to group certain sub-groups of traffic to certain pools. eg. Send image renders (which take longer and can block other traffic) to a dedicated pool of image render boxes. If somehow the entire image render pool died, it would be /ok/ to briefly allow that traffic to hit other servers in our general pool. I find that the longer a config file gets, the more error prone it becomes. Having some 'macros' or 'includes' and some of the techniques I was asking for avoids having to repeat configuration and reduce errors. On Wed, Oct 24, 2012 at 12:41 AM, Baptiste <[email protected]> wrote: > Hi Joel, > > Unfortunately, this kind of configuration is not doable. > Could you tell us why you want to do such thing, what is the real > need for this (even if I have some ideas about it ;) ) > > cheers
