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
> +         server hostB

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 here as it also serves as a destination address. You cannot
use a unix socket nor 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 ?


Reply via email to