On 1/14/19 2:56 PM, Willy Tarreau wrote:
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.

Yes, this is because the "peers" configuration are supposed to be
duplicated without on each haproxy peer. I agree that
"server" should only means "remote peer". It is confusing for the local
peer. Peers are remote or local, contrary to servers which are only
remote peers.

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.

yes, the peers section configurations are identical on each peer belonging to the section.

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.

Ok.

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 ?

I think that all this makes sense as always ;)
I will send a new series of patches for these modifications asap.





Reply via email to