Path to Stable Release: Roadmap

[cijothomas]

Two months ago, we listed critical blockers for this project's first stable release. This issue outlines our planned path forward, including rough timelines. Please be aware that these timelines are based on several assumptions, such as contributor availability, and may need adjustments. We will keep all updated, as more information becomes available.

Target Components for Initial Stable Release:

We have carefully selected the following components for our initial stable release:

Tracing:

• API (opentelemetry crate)
• SDK (opentelemetry-sdk crate)
• OTLP Exporter (opentelemetry-otlp crate)

Metrics:

• API (opentelemetry crate)
• SDK (opentelemetry-sdk crate)
• OTLP Exporter (opentelemetry-otlp crate)

Logging:

• Log Bridge API (opentelemetry crate)
• Tracing Appender (opentelemetry-appender-tracing crate)
• SDK (opentelemetry-sdk crate)
• OTLP Exporter (opentelemetry-otlp crate)

We will intentionally exclude exporters for Prometheus, Jaeger (which is being deprecated), and Zipkin. Existing versions will remain usable; however, our focus will shift primarily to core components, leading to less priority on resolving issues related to these exporters.

Ownership and Responsibilities:

Specific maintainers/approvers will take ownership of distinct areas to ensure accountability and timely progress:

Tracing: @TommyCpp Metrics: @cijothomas Logging: @lalitb

Each owner will define the scope and design principles, establish timelines, and ensure the components meets release targets. While they oversee the overall timeline, we are eager for more contributors to join. Your participation is crucial to our success, and there are plenty of opportunities to get involved.

Balancing Spec Compliance and Timely Release:

Although the OpenTelemetry specification is stable across all signals, we face the challenge of balancing comprehensive spec implementation with our goal of shipping a stable release within a reasonable timeframe. As a result, some components or features may need to be deprioritized to achieve overall project success. Detailed updates for each component will be shared below.

We greatly value your ongoing support and contributions as we approach this significant milestone. For further discussions, please feel free to reach out to any of the owners on Slack or join the discussions on the OTel Rust Slack channel, or reply here/open new issue.

Tracing Scope (Zhongyang)

@TommyCpp to update this:

Have an official recommendation for OTel Tracing vs Tokio-Tracing i.e users have clear guidance on what API to use for instrumenting. Context propagation (in-process and across process) Tracing SDK Tracing OTLP Exporter

Potentially removable from initial version : Baggage

Metrics Scope (Cijo)

• Metrics API with support for sync instruments in beta (and expand to all instruments by RC release) MUST support instrumentation advisory for histogram bucket (This is critical due to Views being not-in-scope)
• Metrics SDK with support for push based exporting (maybe a stretch, but could be expanded to support pull by RC)
  • No support for Views (i.e not possible to default aggregations)
    • No support for multiple readers (expand to multiple by RC release)
    • No support for Exemplars
    • No support for Metric Producers
• Multi-thread tests to prove correctness
• Metrics OTLP Exporter

(Yes, we are going to have to remove existing functionalities for several months. Not a good thing for existing users, but that seems necessary for overall success.)

Timelines Beta release - June 30 2024 RC release - Nov 30 2024 1.0 stable - early 2025.

Logs Scope (Lalit)

@lalitb to update this:

• Appender for tracing with near same performance as by passing OTel API/SDK. (i.e OTel API/SDK should be introduing minimal overhead)
• Logging SDK
• Logging OTLP Exporter
• No support for correlation with spans generated through tracing-opentelemetry subscriber crate.

• Timelines Beta release - June 30 2024 RC release - Aug 30 2024 1.0 stable - Dec 2024.

Common across signals

• Mechanism to suppress own instrumentation : https://github.com/open-telemetry/opentelemetry-rust/issues/761
• Keys, Values and their costs : https://github.com/open-telemetry/opentelemetry-rust/issues/1642

[cijothomas]

As discussed in the community meeting today, above post contains the rough plans. We are still editing it, and once done, will create separate milestones for each release along with planned release date for each of them.

[mladedav]

One very minor naming point

Details

You keep writing `opentelemetry-sdk` crate but that's the only crate that uses underscore in its name. I think I've seen somewhere that there are technical issues with `crates.io` or something else which prevents the rename to `opentelemetry-sdk` but as confusing as it already is, I think it would be better to use that name. Unless the rename is also supposed to happen prior to 1.0?

---

Would it make sense to also include opentelemetry-http as part of the tracing scope? Or part of it, namely opentelemetry_http::HeaderExtractor but from what I've seen everything there is just scaffolding for propagation.

Personally, I think this is important to achieve correct and stable context propagation across processes. Or is the vision that only opentelemetry_sdk::propagation::TraceContextPropagator and opentelemetry::propagation::Extractor would be stabilized and the concrete implementations wouldn't yet?

[cijothomas]

Thanks for the feedback. Yes, opentelemetry-http (at the minimum the propagation part) is critical for OTel Tracing stable.

(I'll enquire more about the _ vs - for sdk crate, to see if we can do something to fix.)

[mladedav]

I also just realized, opentelemetry-http probably should not be stabilized until it is moved to http@1.0. There's already #1674 so I won't go into more detail here, but upgrading it later would be a breaking change.