On Mon, 31 Dec 2007, Willy Tarreau wrote:
> 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 --- >
OK. I'm just very familiar with Cisco and HP cli where it is done like I described. We can do this of course differently.
>>> 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 --- >
This example with IP address only shows how I would like to solve it. Indeed, using IP as a key really sucks, especially when you need to change it - be there, done that. ;) However, server name is not something you need to change quite often.
Also, from programmers' POV, prefixing each sentence means that adding support for above syntax is extremely easy. There is no need to keep a current context (server) and pointer to a server structure and parse everything differently if we are in a different mode. We simply need to extend the current parser to allow a server statements without ip:port-less *if* this server was defined previously and simply modify a current structure instead of creating a new one.
With blocks, we have to rework the parser, so each newline after a "server" is treated in a different way. It probably requires to move server's code to a different function to prevent code duplication.
Adding support for inversion in described way should also be trivial, as all you need to do is to reuse the global flag. And there is no uncertainty if:
server aaa no check backup
means:
no server aaa check
no server aaa backup
or rather:
no server aaa check
server aaa backup
>> 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 --- >
>
> >
>
I'm not found of such "ends", it is very easy to overlook it and you newer know which block it ends exactly, especially if you keep wrong indentation. It works with cli but not with text configs. Please also note that introducing it changes the current syntax as currently "server" does not start nesting and there is no need to end it, the same for "backend", etc. If we force to end each server/backend we will break compatibility, if not we are risking that someone write somethig like:
backend bbb 192.168.0.1:80
server sss2 1.2.3.4:80
maxconn 256
> ... or alternatively :
>
Right, "end backend" is better but it is still harder to implement as you need not only to end current backed but often (but not always) also current server or maybe also something else. My note about changing the syntax is also valid for this example.
> ... than to do :
>
Not sure if this "end" is required here. Each proxy ends with a next proxy (listen/backend/frontend/..) or "defaults" statement, so:
backend bbb
server sss2 1.2.3.4:80 no server sss2 downinter no server sss2 backup
backend bbb1
(...)
> 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 >
The reason is that a server consists of a name and IP:port. Everything else is optionall so if we force IP:port to be defined first there will no possibility for a user to left a phantom (server without IP:port defined). If we don't, one can define such a invalid server.
...
OK, after some thinking for a cfg-file we can also post-check all servers and reject invalid ones like it is done with proxies. No idea how to solve it for cli?
>>>>>> 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? ;) >
Hm, it is only "init" when haproxy starts, it is wrong IMHO to call it initinter, especially it is used for example after a first unsuccessful check.
> I have a problem with "trans". It does not make me immediately think
> about "transition". I think about "transfer", "translate", "transform"
> but not "transition".
transitinter?
> 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.
>
IMHO it should be called same way for both single- and multi-line servers.
Best regards,
Krzysztof Olędzki Received on 2007/12/31 07:13
This archive was generated by hypermail 2.2.0 : 2007/12/31 07:15 CET