On Mon, Nov 18, 2019 at 2:37 PM Daniel Corbett <[email protected]> wrote:
> Hello, > > > On 11/18/19 7:05 AM, Willy Tarreau wrote: > > On Mon, Nov 18, 2019 at 12:06:08PM +0100, Baptiste wrote: > >> When we first designed this feature, we did it with this in mind "if > admins > >> can update a SRV record in a DNS server, they can adjust the weight > >> accordingly". > >> > >> I understand the need, but the response is way too short. It's a global > >> question of precedence in HAProxy from my point of view. > >> I am scared that if we start to adjust things this way, we'll end up > with > >> 1000s of flags overlapping each others and adding complexity on top of > >> complexity. > >> > >> The real question is "what prevents an admin from updating a DNS > record?" > >> Or why they don't failover to A/AAAA records only? > > I must admit I understand a valid use case : have the DNS set up to > advertise > > the list of servers, and let the agent adjust the servers' health based > on > > their load, the fact that they're running backup or OS updates etc. Thus > in > > my opinion, the *use case* makes sense. What I'm unsure about is the > proper > > way to do it, because as you mention, it's more a matter of overall > > consistency between all sources. We could very well instead have a > per-backend > > setting indicating what source to fetch the weight from (agent, dns, > health, > > other?), where to fetch the maxconn from etc. Some may even want to > combine > > these (average, multiply, ...). I'm fine if you prefer to postpone it. > If in > > the end we decide to merge it as-is we could also backport it, and if we > > decide to address it differently, at least we won't have to maintain one > > extra short-lived flag. > > > > Thanks, > > Willy > > > I'm open to ideas on implementation method, definitely not stuck on this > method :) To be honest I was trying to find some "good first issues" > to tackle. > > GitHub request here: https://github.com/haproxy/haproxy/issues/48 > > > Thanks for taking the time to review and provide your input guys! > > > Thanks, > > -- Daniel > > > I replied back on the github issue to re-start conversation on the topic. Based on the answer, I'll give you my go or not :) If the go happens after the release, we can still backport this quick change if this is really useful to people. Baptiste
