On Tue, Oct 10, 2023 at 01:20:13PM +0000, Tristan wrote: > That said, I do have some use-cases at the moment where I actively make use > of SRV records on the backends internally, for which losing support would be > a little annoying, so I can appreciate the will to keep them.
These are among the messy stuff that I would really like to get rid of. Actually making servers appear/disappear based on random responses from DNS servers is a total mess. I remember that we even have some special cases to gracefully handle truncated responses :-( I'm pretty sure that the component that currently maintains your SRV records up to date provides alternate, reliable, mechanisms. These should be the long-term focus. The only thing is that often such mechanisms are provided as libs for some languages or frameworks, or there's also the problem of how to make sure two haproxy nodes learn the same stuff (something as stupid as server IDs and positions that are not kept in sync between nodes with DNS responses, breaking persistence and hashing). Once you have a lightweight external connector that can suck all update notifications and distribute them to your haproxy farm, it suddenly makes all these artificial problems disappear. > > Should this be handled by dpapi and configured via socket api or any > > upcoming api in HAProxy > If dpapi is to become necessary for very dynamic configurations, I just hope > it follows a standard rather than expecting users to write adapters around > since it's unlikely that anything but xDS (or similar) will have significant > adoption in the near future due to the rather high cost of supporting > third-party APIs like those for various projects. Actually one reason why I'm seeing hope in the dpapi precisely is its ecosystem: for the developers working on this, adopting a connector to suck this or that API is "just" a matter of "including a library" (sorry I don't know the Go terminology but you see my point). So it makes it inexpensive to use a standard and complicated to reinvent the wheel. On the opposite, each time we considered trying to adapt to such stuff directly from haproxy, we were still thinking about how to hack something that would barely emulate the standard and would require some manual adjustments in the corners. So I'd rather see such a component as dpapi be the way to integrate with modern dynamic registries and haproxy staying in charge of the data path, continuing to implement transport protocols etc. It's very possible some people will have issues with using the dpapi for certain use cases, and these ones will have to be reported. I think it's also our job in the haproxy core to make sure that more and more of its internal state is easily shared with the dpapi to make that integration as smooth and convenient as possible. Just an example, for a long time some users have been asking to save and reload stats counters upon reload. That's basically impossible to do right now, and we've even seen with the state-file that identifying a server in a changed configuration is very challenging. On the opposite, when the dpapi reloads a config, for it dumping stats and reinjecting them as an opaque field in the reloaded server config is easy because it knows which object is which, there's no guess work to apply. And that's among the features I would like to see very soon because I think it's easy for both components to implement it. > Somewhat the same reason why while the socket api is cool and useful, it > doesn't really work out as nicely as it could when it comes to integrating > it with other software. Exactly! Maybe most software would just like to send JSON requests there and that could ease your tasks. Willy
