On Thu, Apr 07, 2022 at 08:33:10PM +0200, Miroslav Zagorac wrote: > 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.
OK thanks! > 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). Noted. > > 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 Ah yes, I had forgotten about that one! > 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. This alone could be a good way to reopen discussions about SPOE improvements. It was precisely designed to allow such sidecar components to easily coexist, and if it doesn't do it well, we'd need to know why and figure what ought to be done to address this (there are probably plenty of valid reasons). No rush on this, but I think it would be worth discussing this before deciding to restart from scratch for opentelemetry. Willy
