Re: [PATCH] Implement and use generic findproxy and relax duplicated proxy check

Hi Krzysztof,

On Sun, Nov 04, 2007 at 03:04:33PM +0100, Krzysztof Oledzki wrote:
> >$ ./haproxy -V -c -f examples/cttproxy-src.cfg
> >[WARNING] 307/071152 (23816) : Parsing [examples/cttproxy-src.cfg:47]:
> >duplicated proxy 'sample1' with conflicting capabilities: listener/listen!
> >Configuration file is valid : examples/cttproxy-src.cfg
> >
> >I realized that the term "listener" I used to describe a "listen" instance
> >was more confusing than helping.
>
> Personally I would prefer to simply put here "listen". For me proxy is a
> general structure, and "listen", "frontend", "backend" and "ruleset" are
> more detailed instances compliant with cfg keywords.

The problem is that "listen" is a verb while "backend" is a noun, and using the word "listen" in the middle of some sentences makes them totally incomprehensible. The real problem comes from the history of this keyword in the config. Initially, it was the keyword after which we could declare the unique listen address, and now it's a full structure. Also, at many places in the error messages and the logs, the word "proxy" is reported for a proxy of any type. Even the documentation mostly talks about "proxy", and sometimes "instances".

> So, if we put here:
> [WARNING] 307/071152 (23816) : Parsing [examples/cttproxy-src.cfg:47]:
> duplicated proxy 'sample1' with conflicting capabilities: listen/listen!
> then it should be obvious to search for "listen sample1" definition.

At first it was written "...capabilities: listener/listen!" which caused trouble to me. The left part was taken from proxy_type_str() and the right part was args[0]. Then I wanted to fix proxy_type_str() to report "listen" instead of "listener", but that caused some error messages to become even worse :

   "monitor-uri will be ignored for listen 'public'."    "cookie will be ignored for listen 'external'."

The only perfect solution would be to promote the word "proxy" instead of "listen" in all new configurations. But since haproxy does not modify the configurations, there would be no migration process and it will bother people. Maybe we should prepare this anyway, I don't know. After all, if we only document "proxy" everywhere and if "listen" is still silently accepted, it should not cause too much trouble.

> >[WARNING] 307/071427 (24030) : Parsing [test1.cfg:95]: backend 'sample1'
> >has same name as another proxy.
> >[WARNING] 307/071427 (24030) : Parsing [test1.cfg:95]: backend 'sample1'
> >has same name as another proxy.
> >Configuration file is valid : test1.cfg
>
> I'm not sure about this. Usres may get confused why haproxy sometimes
> reports "has same name" (listen & listen) and sometimes not (backed &
> frontend). Maybe we should also put here info about "overlapping
> capabilities"?

That was my first impression too, until I had to fix the configuration which exhibited the problem. I realized that for the administrator, the problem is not that the capabilities are overlapping, it is that the config has been completed by copy-paste and that some entries have been left unrenamed. The initial message emphasizes on the capabilities, while the real thing which needs to be changed is one of the names.

I was even thinking about storing the configuration line number in the proxy struct in order to give hints to the admin about where to look for duplicates.

I have nothing against adding more information (of course), but it should be oriented towards educating the administrator and helping him adopting best practises to fix his config, and not bother him with internal details. I still think that we can talk about capabilities because the doc should at one moment explain how proxies are composed.

Best regards,
Willy Received on 2007/11/04 15:40