On Mon, Nov 18, 2019 at 11:57 AM Willy Tarreau <w...@1wt.eu> wrote:

> Hi Daniel,
> On Sun, Nov 17, 2019 at 10:06:32AM -0500, Daniel Corbett wrote:
> > Hello,
> >
> >
> > I realize that new features are not preferred at the moment but I think
> this
> > might be a usability issue and hopefully it can be considered for
> 2.1-dev,
> > however, it's perfectly fine if it's decided to wait till next.
> >
> > It was noted in GitHub issue #48 that there are times when a
> configuration
> > may use the server-template directive with SRV records and simultaneously
> > want to control weights separately using an agent-check or through the
> > runtime api.  This patch adds a new option "ignore-weight" to the
> > "resolve-opts" directive.
> >
> > When specified, any weight indicated within an SRV record will be
> ignored.
> > This is for both initial resolution and ongoing resolution.
> In my opinion it's small enough to be mergeable. However I have no opinion
> whether this is the best way to handle it or not, so I'll leave it to
> others
> to judge. For example it could be imagined that some would want to keep the
> weight zero as special to take a server out of the farm maybe (though this
> could complicate the logic). If others agree with the patch, I'm fine with
> getting it merged even this late given that it doesn't seem to have side
> effects.
> > I wanted to include  VTC test with this, however, I could not think of an
> > appropriate way to do it as I suspect we may need a "fake dns server"
> > similar to what was made for syslog.
> vtest is really made to test proxies, i.e. have a client on one side, a
> server on the other one, and synchronize them to make sure that what is
> observed precisely corresponds to what is tested, which is the hardest
> part to test on a proxy. It's really not suitable to run other types of
> tests at the moment. Maybe we could imagine improving it to implement a
> DNS responder, but even by doing this we'd start to add some entropy
> (timing between checks causing ordering issues) making the tests harder
> to reproduce.
> If we want to implement some testability for anything related to DNS,
> we'll need to specify in very fine details how we want it to work I
> guess.
> Thanks,
> Willy

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

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

The real question is "what prevents an admin from updating a DNS record?"
Or why they don't failover to A/AAAA records only?


Reply via email to