On Sat, Oct 07, 2023 at 02:55:03PM +0200, Aleksandar Lazic wrote: > Hm, this makes me thinking to have also some mode like mysql,mqtt, what ever > to use it for monitoring or any other purpose.
Good point indeed, these were among the ones that were already discussed in the past. But you get the point, my goal is that we can have something that is not necessarily HTTP just because it's not raw TCP. > Maybe this will then bring up SPOE to a level where the body of a request > can be scanned and bring it to a full WAF level or as WASM filter. It's unrelated. The "mode" defines what processing is being done between both ends and how exchanges are done. The filters like the SPOE one are inserted into an existing protocol. > Are there any plans to have something similar to XDS ( > https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol ) for > dynamic configs at runtime, similar to the socket api and Data Plane API? I used to have such plans a long time ago and even participated to a few udpapi meetings. But at this point I think it's not haproxy's job to perform service discovery, as such mechanisms do not try to replace the load balancers but the humans who configure them. As such it should be a layer on top of it, which currently is represented by the dataplane API, though it could also be anything on top of the dpapi which relies on the dpapi's capabilities. There are multiple reasons for this, the first one being that some changes might be too invasive and require a reload, so the process cannot do that on itself, and another reason is that some discovery code might be readily available in other high-level languages such as Go and not yet in C. A third reason is that those layers do not evolve at the same speed and are not of interest to the same developers. So it's much easier to keep the roles apart and keep haproxy as a pure dataplane that moves bits very fast, and maintain the control plane outside of it. The haproxy developers' time would be much better invested by tightening the relation between dpapi and haproxy in order to ease runtime communication between the two than by spending years implementing the intersection between each new discovery protocol and what can really be done. That's also why I said earlier that I want to eventually remove a part of the DNS code that currently does too much. DNS is not bad when it consists in resolving the address of your server, but it's bad when it's used as the poor man's solution to fill a farm and delivers inconsistent farms between multiple LBs, while saner mechanisms exist. Cheers, Willy
