On 07.04.2022 20:02, Willy Tarreau wrote:
No, really, do not bother doing that. Just tell me which ones are bug
fixes that need to be backported, as we'll backport them the usual way
as part of the regular maintenance process anyway. If you tell me "those
marked bugs ought to be backported wherever they apply", that's already
sufficient, I'll add this note in the relevant commit messages and they'll
automatically flow there.
I will add to each commit a note to which branch it refers. Branches
2.5 and 2.6 are identical in terms of patches; i still have to try how
haproxy 2.4 works with applied patches.
Please don't apply anything for now, you will get patches for 2.4 and
2.[56] branches so you don't waste time with it (some patches don't go
uncorrected).
The naive question here is, does this *need* to run *inside* the
haproxy process ? Can't this be externalized in a sidecar agent
using SPOE, peers or anything else, that would benefit from existing
libs in their native language and not require to write a wrapper ?
That was the reason SPOE was designed in the first place and maybe
it would be time that we stop wasting time writing wrappers for
ephemeral suites.
There is an implementation of opentracing that uses SPOE, but its
usability is highly questionable:
https://github.com/haproxytech/spoa-opentracing
That utility cannot transfer the opentracing context to other
microservices, which is one of the prerequisites for the operation of
the tracing service. Also, SPOE implementation does not allow as many
events as the opentracing filter. That utility is much slower than the
native filter implementation and it simply cannot replace the filter in
question.
--
Zaga <miros...@zagorac.name>
What can change the nature of a man?
