Hi Fred,
first, thanks for reviving this!
On Fri, Jan 11, 2019 at 02:52:24PM +0100, flecai...@haproxy.com wrote:
> +bind [param*]
> + Defines the binding parameters of the local peer of this "peers" section.
> + To avoid some redundancy, and as the <address> and <port> parameters
> + are already provided on "peer" (or "server") lines, they are not supported
> + by "bind" keyword in "peers" sections.
> +
(...)
> + Example:
> + peers mypeers
> + bind ssl crt mycerts/pem
> + default-server ssl verify none
> + server hostA 127.0.0.10:10000
> + server hostB 127.0.0.11:10001
Just thinking loud, I find this a bit confusing : "bind" usually is
followed by an address to bind to. And it's even wider than just the
haproxy culture. Here from what I'm seeing you're using it exactly
like "default-server", i.e. you can pass all default settings but not
the address. Thus I think that having a "default-bind" directive would
remove this confusion.
> + Note: "peer" keyword may transparently be replaced by "server" keyword (see
> + "server" keyword explanation below).
> +
> +server <peername> <ip>:<port> [param*]
> + As previously mentionned, "peer" keyword may be replaced by "server"
> keyword
> + with a support for all "server" parameters found in 5.2 paragraph.
> + Some of these parameters are irrelevant for "peers" sections.
Same here, if "server" also creates a listening address, it's quite
confusing in my opinion.
And this makes me think a bit further. I remember some old discussions
where we were saying that the main problem posed by peers is that they
are forcibly symmetrical ; you cannot use them on a dynamic IP address
or on a set of IP addresses for example because you are not allowed to
put 0.0.0.0 here as it also serves as a destination address. You cannot
use a unix socket nor 127.0.0.1 either, just like it's not possible to
listen both to IPv4 and IPv6 addresses.
And I think that your "bind" + "server" options could solve this in a
very elegant way : what about having "bind" always set the listening
address and "server" always set only the target address ? In this case
we could simply handle the migration by making it an error to have both
"bind" and "peer". And thinking about it, I feel like that's a discussion
we already had in the past.
Thus I think we could end up with this :
First step :
- "peer" does what it currently does, i.e. set both the bind and the
target address ;
- "default-server" applies to the server part of the peers
- "default-bind" applies to the bind part of the peers
=> that's what you did modulo the last option's naming
Then we add this :
- "bind" only sets the bind address and bind options ;
- "server" only sets target addresses and server options ;
And this will also solve the problem of testing peers with vtest, since
this time they will work *exactly* like real bind+servers with their own
addresses :-)
What do you think ?
Thanks,
Willy
