-
Notifications
You must be signed in to change notification settings - Fork 506
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDk/Sampler concepts leaked in API #1043
Comments
I think the only "Sampling" related concepts that should be part of Tracing API are:
Based on the comment (https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/src/trace/tracer.rs#L174-L176), I think this is done to accommodate tracing-opentelemetry crate. Related discussion around that crate : #1032 |
@hdost Moving back to Tracing API stable, as the fix for this (if we chose to), would be in the API itself! |
@open-telemetry/rust-approvers Given the popularity of Please share your thoughts on how best to proceed. My proposal:
|
|
@jtescher any thoughts on changing tracing-opentelemetry to accomodate this? |
From SIG meeting: |
We could look at updating More context for the current implementation is here https://github.com/tokio-rs/tracing-opentelemetry/blob/v0.1.x/src/tracer.rs#L14-L27 |
https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry/src/trace/tracer.rs#L277
SamplingResult
is the type returned by Samplers, and it is a pure SDK concept.If this was unintentional, we should remove it before 1.0 stable release.
Similar: #1042
The text was updated successfully, but these errors were encountered: