On Sun, Dec 30, 2007 at 09:25:31PM +0100, Krzysztof Oledzki wrote:
>
>
> On Sun, 30 Dec 2007, Willy Tarreau wrote:
>
> >On Sun, Dec 30, 2007 at 02:40:18PM +0100, Krzysztof Oledzki wrote:
> >>>Yes, that's exactly that. Intuitively, I think we can keep the principle
> >>>of the "no" prefix to disable anything. For instance :
> >>>
> >>> default server check inter 1000
> >>> server xxx
> >>> server yyy no check backup
> >>
> >>If we would like to keep a cisco-like cli then it should be something
> >>like:
> >> default server check inter 1000
> >> server xxx (...)
> >> server yyy (...) backup
> >> no server yyy check
> >
> >Hmm not really because "server" is sub-level in itself even if it's on
> >one line. If we could extend the language, we would have :
> >
> > server xxx
> > no check xxx
> > backup
>
> As far as I know the cisco IOS syntax:
>
> --- cut here ---
> r4(config)#ip tcp selective-ack
> r4(config)#no ip tcp selective-ack
> r4(config)#ip tcp no selective-ack
> ^
> % Invalid input detected at '^' marker.
> --- cut here ---
I agree with you. I was not saying that *cisco* did support this, but that we could consider "server xxx" as one block in which case it would make sense to be able to prefix its parameters with "no".
> >And in this case "no check" would make sense. BTW, I still don't know
> >how we could proceed to support multi-line servers like this. Maybe
> >the solution would simply be to support either a full-line or just the
> >server name on one line, followed by its parameters. The danger is that
> >servers share some keywords with the proxies (maxconn, source, usesrc,
> >...). But after all, people have no problem understanding cisco configs
> >which work like this, I don't see why it could be problematic.
>
> IMHO it would be both easier to read and implement one-level of nesting
> similar to:
>
> *Cisco example:
> --- cut here ---
> router bgp 65320
> no synchronization
> bgp router-id 192.168.0.4
> bgp log-neighbor-changes
> bgp update-delay 15
> neighbor 192.168.0.1 remote-as 65320
> neighbor 192.168.0.1 description ASP-R1
> neighbor 192.168.0.1 fall-over
> neighbor 192.168.0.1 next-hop-self
> neighbor 192.168.0.1 send-community
> neighbor 192.168.0.1 soft-reconfiguration inbound
> neighbor 192.168.0.1 maximum-prefix 8192 restart 15
> neighbor 192.168.0.2 remote-as 65320
> neighbor 192.168.0.2 description ASP-R2
> neighbor 192.168.0.2 fall-over
> neighbor 192.168.0.2 next-hop-self
> neighbor 192.168.0.2 send-community
> neighbor 192.168.0.2 soft-reconfiguration inbound
> neighbor 192.168.0.2 maximum-prefix 8192 restart 15
>
> r4#conf t
> Enter configuration commands, one per line. End with CNTL/Z.
> r4(config)#router bgp 65320
> r4(config-router)#neighbor 192.168.0.99 send-community
> % Specify remote-as or peer-group commands first
> --- cut here ---
To be honnest, having manipulated such configurations too, I'm really not fond of them because there is one parameter which is constantly repeated (here the neighbor's IP which is used as a key). This becomes very unconvenient when you need to change this IP address when doing tests.
> Old (current), still supported config:
> --- cut here ---
> backend bbb
> server sss2 192.168.10.21:80 cookie sss2 check inter 9000 fall 4 weight 40
> --- cut here ---
>
> New:
> --- cut here ---
> backend bbb
> server sss2 192.168.10.21:80
> server sss2 cookie sss2
> server sss2 check
> server sss2 inter 9000
> server sss2 fall 4
> server sss2 weight 40
> no server sss2 downinter
> --- cut here ---
Eventhough it's less annoying than in the case of the cisco with the IP address, I still find this method somewhat annoying. However, it *is* logical, I do not discuss it.
What would be the real reason to limit ourself to only one indentation level ? If we consider that the first word which does not match the block's keyword list means we're out of the block, it should be fine. And we can even add an "end [server]" explicit termination to solve any dangerous situations where the proxy's "source", "maxconn", or "cookie" parameters would be set after servers.
Also, when we have a CLI, I find it more convenient to do :
config> backend bbb
backend bbb> server sss2 server sss2> no downinter server sss2> no backup server sss2> end backend bbb> end
... or alternatively :
config> backend bbb
backend bbb> server sss2 server sss2> no downinter server sss2> no backup server sss2> end backend
... than to do :
config> backend bbb
backend bbb> no server sss2 downinter backend bbb> no server sss2 backup backend bbb> end
Of course it's just a matter of taste, but I like to be able to configure blocks in their own context provided the context is not too deep, of course (eg: not like BGP configuration on alteon).
> New invalid:
> --- cut here ---
> backend bbb
> server sss2 cookie sss2
> (...)
> --- cut here ---
> parsing [haproxy.cfg:66]: multiline definition of server sss2 must begin
> with ip:port
I see no reason why the IP:port should be defined first. In the past, the "mode" parameter had to be specified first in the "listen" sections, and it was very annoying because it did not let the user enough freedom to structure their configuration like they wanted. This has changed since the introduction of the default sections I think.
> >>>>I'll cook a RFC patch for both
> >>>>transcheck and a "default server" statement.
> >>>
> >>>That would be very nice. BTW, I think that we should find another term
> >>>for "transcheck", as this one is not intuitive at all. I think that the
> >>>word "inter" should appear in it. Also, while initially I thought about
> >>>"fastinter", the name would not make much sense if this value can be
> >>>larger than inter. Maybe something such as "altinter" or simply "inter2"
> >>>?
> >>>
> >>>Also, some people have already suggested to consider an optional even
> >>>slower interval for down servers, because there's not much emergency
> >>>to detect that a server is going up. This one might be called
> >>>"downinter".
> >>>So at the end, we would have :
> >>>
> >>>- the default interval
> >>>- a second interval used during init time and state changes
> >>>- an optional third interval to replace the default interval when
> >>> servers are down
> >>
> >>Or maybe we can just call them upinter and downinter:
> >>
> >> - the default interval: inter
> >>
> >> - a second interval used during init time and when servers are up
> >> but "sv->health < s->rise + s->fall - 1": upinter
> >
> >It's not really when servers are up, but when they are changing state.
> >IMHO this is valid in both directions. This is also what allows you to
> >have very long "downinter". For instance, if you check a down server
> >every minute, once you detect a change you can check it every second
> >to speedup the recovery process. Maybe "chginter" ? (I don't like it
> >much either).
>
> transinter? ;)
or initinter ? :-)
I have a problem with "trans". It does not make me immediately think about "transition". I think about "transfer", "translate", "transform" but not "transition".
This is beginning to remind me the stupid names I had to find for the timeouts until I got enough of them and used a "timeout" prefix to name all others.
Maybe the interval will finish like this. Using "inter 10000" to set the default interval, and "inter transition 500" or "inter down 20000" for the other ones. While this could quickly get boring on a single line for each server, it may get more useable with default servers and server subsections.
Best regs,
Willy
Received on 2007/12/31 00:15
This archive was generated by hypermail 2.2.0 : 2007/12/31 00:30 CET