On Thu, Apr 07, 2022 at 07:15:21PM +0200, Miroslav Zagorac wrote: > On 07.04.2022 18:27, Willy Tarreau wrote: > > Hi Miroslav! > > > > Hello Willi, > > at first I would generally say that I did not think that some of these > patches could be backported to older versions of haproxy. I will look > at what can be applied to older versions and send group patches for > each of them to the mailing list tomorrow (one tar file per version).
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. > > On a related note, I've just discovered this that you might be interested > > in: > > > > https://github.com/haproxy/haproxy/issues/1640 > > > > The reporter mentions that apparently OT is becoming deprecated. If you > > find some info about this and if it can affect our users (depending on > > how long it will take before being unsupported if at all), possibly that > > we should think about a startup warning or something like this. I do > > not know what it implies for it to become deprecated, if all of its > > components are available in LTS distros, users will not care. The problem > > is more if users have to download components from sites that risk stop > > providing them. > > > > Yes, i saw that.. after the opentracing filter in haproxy was implemented i > looked at what should be done to add support for opentelemetry. > > Unfortunately, although this is an upgrade of the existing telemetry > system, the API for use is not compatible. That's sad but I'm not surprised at all :-( We're exactly witnessing what I warned against 2 years ago about it, "being popular doesn't mean being standard and probably means might disappear at any point in time or be replaced by something incompatible". That's why it's in addons/ and not in the core, by the way. > To begin with, it is necessary to write a C wrapper for > opentelemetry-cpp, which will take considerable time. Then it is > necessary to write a new haproxy filter (or redesign the existing > one so that it can use both API). 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. > This is the github repository of opentelemetry API for C++: > https://github.com/open-telemetry/opentelemetry-cpp > > As for opentracing, I think it will be supported for some time because > opentelemetry is a relatively new standard Warning, what I'm reading here is not that it's a standard but a specification: https://github.com/open-telemetry/opentelemetry-specification A specification can be implemented and become popular, but it can change at its authors' will. The most ephemeral ones are those that come with code because they're quick to adopt, there's little investment from 3rd parties, meaning that there's little resistance to replace them by new ones. > and it is not designed to be > a replacement for opentracing without a change in client software. For > new development it is recommended to use opentelemetry. OK thus at least it means that opentracing is still not dead for existing deployments, though its days (and of the libs it relies on) are probably counted already. > I hope I have answered at least some of the questions in some useful > way. :) For sure, thank you! Willy
