Hi Christopher, Thank you for starting the discussion here.
>Worst, other parts of HAProxy evolved, especially applets part, making maintenance ever more expensive. Can we elaborate on what makes maintenance expensive? >We must be realistic on the subject, there was no real adoption on the SPOE and this partly explains why no time was invest on it. My company primarily uses SPOE in cases where we've to connect with non-http downstreams, for example, connecting to the data layer (Couchbase etc) that makes the proxy stateless. Other uses-cases are SSO implementation etc. We are a new user to HAproxy, with multi-million QPS on HAproxy already, and we've plans to ramp multiples of that in the coming year or two. >Now we are open to discussion on this subject. Let us know your feeling and if you have any suggestion, we will be happy to talk about it. Our goal at my company has been to not modify HAproxy core and still add features to it without running in the same memory space as HAproxy for safety. Of course, we use config DSL and lua as much as possible, but it falls short in terms of writing complex business logic. (non-http downstreams etc). If it's not SPOE, what is a true replacement? With my limited knowledge, not a true replacement though, maybe lua filter API and then write these complex in-flight operations in Rust? With the learnings from today, what would be the ideal way to replace it, considering we had engineers to maintain it? Slightly off-topic, SPOE has its flaws too though. One of our use-cases is to stream (kafka) HTTP traffic information (cookies, request data etc) in an efficient fashion and we actually did not use SPOE as the cost to exchange information was too high. In this particular case, we ended up streaming data via txn/req variables to logs instead (ring buffer). Thanks, Abhijeet On Fri, Mar 15, 2024 at 7:10 AM Christopher Faulet <cfau...@haproxy.com> wrote: > > Hi all, > > It was evoked on the ML by Willy and mentioned in few issues on GH. It is now > official. The SPOE was marked as deprecated for the 3.0. It is not a pleasant > announce because it is always an admission of failure to remove a feature. > Sadly, this filter should be refactored to work properly. It was implemented > as > a functional PoC for the 1.7 and since then, no time was invest to improve it > and make it truly maintainable in time. Worst, other parts of HAProxy evolved, > especially applets part, making maintenance ever more expensive. > > We must be realistic on the subject, there was no real adoption on the SPOE > and > this partly explains why no time was invest on it. So we are really sorry for > users relying on it. But we cannot continue in this direction. > > The 3.0 is be an LTS version. It means the SPOE will still be maintained on > this > version and lower ones for 5 years. On the 3.1, it will be marked as > unmaintained and possibly removed if an alternative solution is implemented. > > It remains few months before the 3.0 release to change our mind. Maybe this > announce will be an electroshock to give it a new lease of life. Otherwise it > is > time to find an alternative solution based on an existing protocol. > > For all 3.0 users, there is now a warning if a SPOE filter is configured. But > there is also a global option to silent it. To do so, > "expose-deprecated-directives" must be added in the global section. > > Now we are open to discussion on this subject. Let us know your feeling and if > you have any suggestion, we will be happy to talk about it. > > Regards, > -- > Christopher Faulet > -- Cheers, Abhijeet (https://abhi.host)
