Stability : Tracing

[hdost]

This is a tracking ticket to cover the steps and have a wholistic view over the Tracing
Multiple members should cross validate, and create issues under the API Milestone for any potential blockers

Stability API

• Gap analysis between tokio tracing
  • maybe open a ticket on tokio tracing about aligning on feature?
• Ensure that the features are documented well
  • Setup categories could help [Bug]: cargo package features are ill documented #1464
• Validate Matrix Compliance
  • TracerProvider
  • Trace / Context interaction
  • Tracer
  • SpanContext
  • Span
  • Span attributes
  • Span linking
  • Span events
  • Span exceptions
  • Sampling
  • New Span ID created also for non-recording Spans
  • IdGenerators
  • SpanLimits (Optional)
  • Built-in SpanProcessors implement ForceFlush spec
  • Attribute Limits (Optional)
  • Fetch InstrumentationScope from ReadableSpan
  • Resource - @hdost: I'm not sure if we need this stable, but possibly for Traces to be stable
    • Create from Attributes
    • Create empty
    • Merge (v2)
    • Retrieve attributes
    • Default value for service.name
    • Resource detector interface/mechanism
    • Resource detectors populate Schema URL
    • Exporters
    • Context
• Public API Review
  • Validate we don't have too much in the Public API.
• Follow Rust Guidelines - https://rust-lang.github.io/api-guidelines/checklist.html
• DogFood Testing
• Add Performance testing
  • Stress tests can provide insight into individual operations
  • Integration testing - This can provide insight on the overall performance
• Get a review from the TC
• Release a series of Release candidates (number needed depends on the feedback)
• Mark tracing as stable.

For what is defined as stable for tracing:

We're defining stable as:

• opentelemetry-api tracing
• opentelemetry-sdk tracing
• opentelemetry-jaeger - Jaeger is the most used exporter.(Deprecated aslo)
• opentelemetry-otlp tracing

Zipkin can be stable after GA for tracing.

Docs:

• Add more context for how to choose runtime and why we need runtime SIGINT ignored when using .install_batch(opentelemetry::runtime::Tokio) #731

Validate:
https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md#traces

Historical #330

[hdost]

@open-telemetry/rust-approvers It's been a couple months like this, I know I'm not as active as the rest of you, but I feel like this wasn't intended.

[jtescher]

Yeah we're not currently 1.0, but we're pretty close to stable with tracing could probably commit to a 1.0 at this point and do a 2.0 if we need breaking changes.

[hdost]

Perhaps we could add any last tickets to get it to Stable in https://github.com/open-telemetry/opentelemetry-rust/milestone/1

[TommyCpp]

Yeah I like the idea to be more organzied on our milestone.

[hdost]

I added basically everything related to core SDK functionality to the stabilization, if there's anything that could done after then I'd say feel free to add labels.
I created a few
release:after-stable
release:allowed-for-stable
release:required-for-stable
I modeled them off the Specification Repo's GA related ones.

[hdost]

For spec adherence maybe we stick with a specific release for now https://github.com/open-telemetry/opentelemetry-specification/releases/tag/v1.26.0 is the lastest. And then if something comes in then we can can defer for the purpose of getting to stable. Typically this will be better since the spec is only point releases.