Skip to content

Change default propagator in unconfigured API #930

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.

Sign up for GitHub

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

Merged
merged 19 commits into from
Sep 18, 2020
Merged

Change default propagator in unconfigured API #930

Show file tree
Hide file tree
Changes from 15 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
View file
Open in desktop
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
29 changes: 21 additions & 8 deletions specification/context/api-propagators.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -267,14 +267,27 @@ 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 should provide a way to obtain a propagator for each supported
Copy link
Member

Choose a reason for hiding this comment

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

should, SHOULD or MUST?

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually I'd prefer to have this as a MAY - we still need to decide whether TraceContext and Baggage Propagators will be in the API or in a separate package (the latter seemed to have slightly more approvals).

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'd go with MUST. Not much use of API if there is no way to propagate context. @carlosalberto are you thinking of the long term vision where context just floats without the need for any API? Is it why you suggest "MAY"?

Copy link
Contributor

Choose a reason for hiding this comment

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

Fine with going with MUST, as this is what we have right now. Observe that we already specified that, at least for B3 and Jaeger, the Propagators ought to live in extension packages - so you may need to be concise and mention Baggage + TraceContext here.

Copy link
Member Author

Choose a reason for hiding this comment

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

this is about API surface. API must provide a means to help with extracting and injecting the context without the need to import special propagation package.

`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.

**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 when used unconfigured. Context
propagation may be used for various telemetry signals - traces, metrics, logging
and more. Therefore, context propagation MAY be enabled for any of them. For instance,
a span exporter may be left unconfigured, although the trace context is being propagated.

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.

### Get Global Propagator

Expand Down