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

OpenTracing Bridge: allow more generic carriers #2141

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

bboreham
Copy link
Contributor

@bboreham bboreham commented Jul 29, 2021

Instead of insisting that the carrier is an HTTPHeaders, cast it or adapt it to the interface we need - TextMapCarrier.

It's a bit long-winded to wrap the read and write side separately, but this gives maximum flexibility.

Fixes #2137 - @kvrhdn has used this fork to create a working program.

@codecov
Copy link

codecov bot commented Jul 29, 2021

Codecov Report

Merging #2141 (8c48780) into main (1884de2) will increase coverage by 0.2%.
The diff coverage is 78.7%.

Impacted file tree graph

@@           Coverage Diff           @@
##            main   #2141     +/-   ##
=======================================
+ Coverage   75.7%   75.9%   +0.2%     
=======================================
  Files        178     178             
  Lines      11703   11740     +37     
=======================================
+ Hits        8864    8922     +58     
+ Misses      2614    2584     -30     
- Partials     225     234      +9     
Impacted Files Coverage Δ
bridge/opentracing/bridge.go 53.1% <78.7%> (+9.5%) ⬆️
sdk/trace/batch_span_processor.go 80.2% <0.0%> (-1.0%) ⬇️
exporters/jaeger/jaeger.go 91.1% <0.0%> (+0.8%) ⬆️

@kvrhdn
Copy link
Contributor

kvrhdn commented Jul 29, 2021

I can confirm this fixes our issue, propagation context can be injected and extracted without error now 🙂

Copy link
Contributor

@MrAlias MrAlias left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution, it is definitely welcomed as we ultimately want to support more than just HTTP carriers for the OT bridge.

These changes need to include tests. Primarily the tests need to ensure behavior of the introduced types are preserved.

bridge/opentracing/bridge.go Show resolved Hide resolved
bridge/opentracing/bridge.go Outdated Show resolved Hide resolved
bridge/opentracing/bridge.go Outdated Show resolved Hide resolved
bridge/opentracing/bridge.go Outdated Show resolved Hide resolved
@hickeyma
Copy link
Contributor

Ping @bboreham. Rebase needed and some feedback to look at.

@bboreham
Copy link
Contributor Author

Ack. It hasn't been high enough up my priority list lately.

Instead of insisting that the carrier is an HTTPHeaders, cast it
or adapt it to the interface we need - TextMapCarrier.

Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
Suggested by Tyler Yahn <MrAlias@users.noreply.github.com>

Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
Values stored in http.Header get title-cased, i.e. `traceparent` will
turn into `Traceparent`. Since HTTPHeadersCarrier.ForeachKey does not
undo this change, special-case that one type with a different wrapper
that will allow the value to be fetched.

Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
This is not currently used in normal functioning of Inject and Extract,
but might get used in future so give it some testing now.

Test adapted from `open-telemetry/opentelemetry-go/propagation/propagation_test.go`

Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
@bboreham
Copy link
Contributor Author

Rebased and added unit tests for the Inject/Extract functionality added in this PR.

Note that ot.HTTPHeadersCarrier needs special treatment - Set() modifies the keys to meet HTTP header expectations - so we can't use the generic wrapper I added in that case.

It appears baggage was never propagated by BridgeTracer, so that is not included in the test.

Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
@Aneurysm9
Copy link
Member

Does #2911 meet the needs here, or is there more required?

@bboreham
Copy link
Contributor Author

bboreham commented Jul 10, 2022

Does #2911 meet the needs here

Strictly no, however I think #2911 makes it easier to work around the deficiency.

Perhaps you will update the doc says it should work with TextMapWriter?
EDIT that doc is in OpenTracing so I realise OpenTelemetry would not update it.

Do you have any response to #2141 (comment) ?

@zalegrala
Copy link

@MrAlias Do you have any further feedback for this PR please?

@@ -635,18 +674,22 @@ func (t *BridgeTracer) Inject(sm ot.SpanContext, format interface{}, carrier int
if builtinFormat, ok := format.(ot.BuiltinFormat); !ok || builtinFormat != ot.HTTPHeaders {
return ot.ErrUnsupportedFormat
}
hhcarrier, ok := carrier.(ot.HTTPHeadersCarrier)
// If carrier implements the required interface directly, use that
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// If carrier implements the required interface directly, use that
// If carrier implements the required interface directly, use that.

if !ok {
return ot.ErrInvalidCarrier
tmWriter, ok := carrier.(ot.TextMapWriter) // otherwise see if we can wrap it
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
tmWriter, ok := carrier.(ot.TextMapWriter) // otherwise see if we can wrap it
tmWriter, ok := carrier.(ot.TextMapWriter) // Otherwise, see if we can wrap it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OpenTracing bridge: BridgeTracer.Inject errors with ErrInvalidCarrier
6 participants