On Tue, Oct 20, 2015 at 07:36:20PM +0200, Lukas Tribus wrote: > Hi, > > > >> A simple option in the resolvers section to instruct HAPoxy to not > >> forgive on NX and failover to next family: > >> option on-nx-try-next-family > > > > I personally find this confusing from the user's point of view. > > Agreed, we should have good and safe defaults, and address corner > cases with additional options, not the other way around.
Definitely. We used to know this situation till 1.4 included with http working in tunnel mode by default and not doing the right thing by default. Many of the problem reports were caused by the fact that newcomers didn't know such specificities. > > When you know that you can only use IPv4 to join the next server, I > > think this : > > > > server remote1 remote1.mydomain check v4only > > > > is more obvious than this : > > > > option on-nx-try-next-family > > server remote1 remote1.mydomain check prefer-ipv4 > > Actually I think "v4only" would be "prefer-ipv4" without > on-nx-try-next-family, right? Anyway, I agree. Yes that's it. > Without automatic AF fallback and without ANY queries, the > "prefer" keyword actually is restricting, and not preferring. I would simply ignore prefer when v[46]only is set. > > Also, it covers the case where some servers are known to support both > > protocols while others are limited. This allows for example to join > > the same remote server over two possible families behind a DSL line > > which uses a random IP address after each reconnection : > > > > server home-v4 home-v4.mydomain check v4only > > server home-v6 home-v6.mydomain check v6only > > > > And since we already have v4only/v6only on bind lines, the analogy > > seems easy to remember. > > The behavior with v4only or v6only is quite obvious, we just query that > particular address family, but let me clarify: you are implying that > without v4only/v6only keyword, we query one address family and then > fallback to the other address family in case we get a NX response, right? Yes that's it. And in this case it's prefer that gives the ordering. > I think thats a good solution. Thanks :-) > Question: are we still talking about 1.6 here? It seems we have to > make some intrusive changes that may break configurations (but they > seem mandatory to get consistent and predictable behavior). I don't know. I'm always only focused on the combination of user-visible changes and risks of bugs (which are user-visible changes btw). So if we can do it without breaking too much code, then it can be backported. What we have now is something which is apparently insufficient to some users so we can improve the situation. I wouldn't want to remove prefer-* or change the options behaviour or whatever for example. > By the amount of people that already hit the ANY issue (3 or more?), > I would say we better break a small number of configurations between > 1.6 and 1.6.1, Normally we don't break them. Currenly prefer can pick any of two families after a response to an ANY request, which is what is still currently being done. It only doesn't retry after it tries a specific family. The only difference will be that if a config reports NX for, say, A, then today it doesn't retry and will cause the server to fail while after the change it will allow the server to continue in v6 or to fail as well. So with this change we will be very close to the current behaviour, and offer everyone the option to fix their preference and make them restrictions. > then having to deal with the fallout of the ANY issue > (because the ANY removal changes resolve-prefer behavior as well) > for the time that 1.6 is supported. Absolutely. We had such related discussions with Baptiste during the design and for many such choices, it was hard to get responses from the users asking for the feature (and several of them were disagreeing on a number of possibilities). It's common in fact, people want something "very simple" and oversee the hidden complexities since corner cases is just for others, they don't happen for them. So we decided to go the modest route and see if anything required to be enforced. I still think it was the best option. Thanks very much for sharing your opinion, that definitely helps! Willy
