Skip to content
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

Change default propagator in unconfigured API #930

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
d693fb9
note on default propagators
SergeyKanzhelev Sep 9, 2020
5a86d55
changelog update
SergeyKanzhelev Sep 9, 2020
1068789
pr number
SergeyKanzhelev Sep 9, 2020
c1163f0
addressed PR feedback
SergeyKanzhelev Sep 9, 2020
8c780e3
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
21661b0
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
07beb2b
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
0d5874c
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
7d7373d
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
be8db72
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
5e5e396
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
8291c18
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
8fb1886
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
ff6c08d
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 11, 2020
d3dcff8
Merge branch 'master' into defaultPropagatorsVariant
SergeyKanzhelev Sep 11, 2020
6102d64
Merge remote-tracking branch 'upstream/master' into defaultPropagator…
SergeyKanzhelev Sep 16, 2020
3840f9d
a few clarificaiton to address PR review
SergeyKanzhelev Sep 16, 2020
3f44162
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 17, 2020
270de4a
Update specification/context/api-propagators.md
SergeyKanzhelev Sep 17, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,8 @@ release.

New:

- Default propagators in un-configured API must be no-op
([#930](https://github.com/open-telemetry/opentelemetry-specification/pull/930)).
- Define resource mapping for Jaeger exporters
([#891](https://github.com/open-telemetry/opentelemetry-specification/pull/891))
- Add resource semantic conventions for operating systems
Expand Down
31 changes: 23 additions & 8 deletions specification/context/api-propagators.md
Original file line number Diff line number Diff line change
Expand Up @@ -267,14 +267,29 @@ Required arguments:

## Global Propagators

Implementations MAY provide global `Propagator`s for
each supported `Propagator` type.

If offered, the global `Propagator`s should default to a composite `Propagator`
containing the W3C Trace Context Propagator and the Baggage `Propagator`
specified in [api-baggage.md](../baggage/api.md#serialization),
in order to provide propagation even in the presence of no-op
OpenTelemetry implementations.
The OpenTelemetry API MUST provide a way to obtain a propagator for each
supported `Propagator` type. Instrumentation libraries SHOULD call propagators
to extract and inject the context on all remote calls. Propagators, depending on
the language, MAY be set up using various dependency injection techniques or
available as global accessors.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's meant by "global accessors"? Via global getters?
We could also more generically say "available as global properties on the API".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what's written is also generic enough. Let me know if this is blocking

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not blocking (I already approved the PR) but a bit unclear to me.


**Note:** It is a discouraged practice, but certain instrumentation libraries
might use proprietary context propagation protocols or be hardcoded to use a
specific one. In such cases, instrumentation libraries MAY choose not to use the
API-provided propagators and instead hardcode the context extraction and injection
logic.

The OpenTelemetry API MUST use no-op propagators unless explicitly configured
otherwise. Context propagation may be used for various telemetry signals -
traces, metrics, logging and more. Therefore, context propagation MAY be enabled
for any of them independently. For instance, a span exporter may be left
unconfigured, although the trace context propagation was configured to enrich logs or metrics.

Platforms such as ASP.NET may pre-configure out-of-the-box
propagators. If pre-configured, `Propagator`s SHOULD default to a composite
`Propagator` containing the W3C Trace Context Propagator and the Baggage
`Propagator` specified in [api-baggage.md](../baggage/api.md#serialization).
These platforms MUST also allow pre-configured propagators to be disabled or overridden.

### Get Global Propagator

Expand Down