Giters

NAlexPear / tracing-stackdriver

Stackdriver-compatible tracing Subscriber

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for other versions of open telemetry

ivan-brko opened this issue · comments

commented

At the moment there is only one feature flag for open telemetry, and it uses version 0.20.

Would it make sense to have something similar to https://docs.rs/tracing-actix-web/latest/tracing_actix_web/ (feature flag per open telemetry version)? If so, is there a plan for something like this? I'm willing to try working on it if such a PR would be accepted.

commented

Thanks for opening this issue!

I figured that tracing-stackdriver might need something like this at some point, but hoped that we could get away with supporting only one version of opentelemetry in the latest version at a time and directing folks to pin to an earlier version of tracing-stackdriver if they needed support for a different otel version.

But if there's a need for multi-version support among users, and there's a concrete reason why pinning to an earlier version of tracing-stackdriver wouldn't suffice, then I'm open to the idea. My requirements would be that:

  1. it actually needs to be useful to users (for example: what version of opentelemetry would you like to see that isn't supported in previous versions of this library?)
  2. we should have a clear support policy for which opentelemetry versions we'll support in the latest version of this library. Since opentelemetry is pre-1.0, I don't want to commit to supporting any unstable version of the upstream library indefinitely. So a multi-version policy would be something like agreeing to support the last three versions of opentelemetry in the latest version of this library.

Thoughts?

commented

Hey, thanks for the fast reply :)

  1. I'm new to the OpenTelemetry ecosystem, so I might be missing something.
    I am trying to set up a project that's running on GCP and is using Actix Web and I had issues with using just the latest versions of all the dependencies, the project compiles but logs weren't coming through to GCP Log Explorer. I downgraded other tracing dependencies I have in the project (I have several dependencies to connect tracing, actix, stackdriver, opentelemetry...) to match tracing-stackdriver version of open-telemetry (0.20, latest being 0.21 in other libraries) and logs are getting exported as expected.
    So, I don't need to be able to select a version of OpenTelemetry for this dependency, if the policy is to always be on the latest version that would work as well, but being able to select a version is a pattern I noticed in other libraries so I thought that it would maybe be an improvement here and a good place for me to start going deeper into the ecosystem.

  2. Is there an already existing policy for this library, which versions of opentelemetry will get supported and how soon?

commented

The "policy" (loosely-enforced) is to try our best to keep up-to-date with the latest opentelemetry release on the latest version of this crate. So that's my fault for not keeping up-to-date!

I'll do a round of dependency upgrades and publish that as version 0.9.0 of this crate shortly.

commented

@ivan-brko the opentelemetry dependency is now updated in v0.9.0 🚀 Since this should solve your specific actix <-> tracing-stackdriver interop issue, I'm going to close this GitHub issue.

If, in the future, you find that there is a feature that you need in the latest version of tracing-subscriber and you need support for earlier versions of opentelemetry, then I'd be happy to accept pull requests for multi-version support of specific dependencies (subject to the requirements I mentioned above). Same for anyone else that lands on this page via Google!

Thanks again for raising this issue 👍

commented

Great, thanks for the help!