Clean up Tracing API spec, clarify Tracer vs TracerProvider. #619
Conversation
Oberon00
requested review from
bogdandrutu,
c24t,
carlosalberto,
iredelmeier,
jmacd,
reyang,
SergeyKanzhelev,
tedsuo,
tigrannajaryan and
yurishkuro
as code owners
Co-authored-by: Reiley Yang <reyang@microsoft.com>
Co-authored-by: Yuri Shkuro <yurishkuro@users.noreply.github.com>
Oberon00
force-pushed
the
cleanup-trace-api
branch
from
bbc1771 to
95eb589
Compare
|
|
||
| The TracerProvider MAY provide methods to update the configuration. If | ||
| configuration is updated (e.g., adding a `SpanProcessor`), | ||
| the updated configuration MUST also apply to all already returned `Tracers` |
There was a problem hiding this comment.
This can be achieved either by allowing to work with an outdated configuration or
by ensuring that new configuration applies also to previously returnedTracers.
From the API, I would expect a SHOULD and not a MUST here
There was a problem hiding this comment.
This is the SDK spec. The API spec allows an arbitrary implementation to "to work with an outdated configuration", but the spec for the official OpenTelemetry SDK can be stricter.
|
Just about everything being said about Providers and globals in this PR applies to Meters and MeterProviders. I filed #587 asking that we separate the specification for Providers so that we are not duplicating this kind of text between the two. The only trace-specific aspects that I see here are in the examples: "for example, in Tracing, the active span is per-provider". Could we split this document out of the tracing API/SDK and create a dedicated place for this content? |
|
I think having a general definition for Foo vs FooProvider could very well make sense, but this is out of Scope for this PR (see issue #587). |
carlosalberto
added
spec:trace
|
@open-telemetry/technical-committee This is ready to merge (addressing TC because I think you are the only ones with merge access). |
|
@carlosalberto I think this is mainly area:api. |
This cleans up the tracing API spec, and clarifies what TracerProviders/Tracers are (not) allowed to do for different Tracers.
It also removes some wording regarding propagators that seems obsolete by now (OTEP66).