-
Notifications
You must be signed in to change notification settings - Fork 604
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
Remove Traceparent Extension Handling #2873
Remove Traceparent Extension Handling #2873
Conversation
Also fix the config-tracing link.
The following is the coverage report on the affected files.
|
/assign @n3wscott |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ian-mi Why are you removing the traceparent transformer & the traceparent handling in message_receiver? protocol/http.Message
, protocol.http/WriteRequest
& protocol.http/WriteResponse
doesn't handle the tracing, these still needs to be handled by eventing directly.
Message_receiver seems to be the wrong place to inject tracing attributes, we should inject them as close to actually sending the event as possible in order to include any additional spans created during fanout or in the SDK. The intention behind adding trace handling to the cloudevents client was to delegate handling of tracing extensions to the SDK and avoid duplicating code across components and protocols. Is there a reasonable place to put this in the SDK? Ideally we should avoid re-implementing this per-protocol since this code is mostly protocol agnostic (except for the ochttp plugins which must be added for HTTP). |
@ian-mi honestly I think the code we have now in message_receiver still doesn't work 😄 I've opened another PR here: #2862, but i'm going a little blindly on tracing b/c i'm not an expert, i definitely need some help to fix it 😄. I honestly don't want to implement in sdk-go the tracing at btw in message_receiver the trace is not injected, it's just "prepared" i think... |
THANK YOU SO MUCH <3 /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ian-mi, n3wscott The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold |
Traceparent is an official CloudEvents extension. It doesn't seem specific to Knative. Why shouldn't the SDK implement it? Is there a technical reason? |
This function breaks tracing by setting the transport HTTP client. Users of this function should already be migrated to NewDefaultHTTPClient.
c4536e7
to
c8b9c10
Compare
I think that we should look for a way to encapsulate this functionality in the SDK as requiring every implementation to deal with setting tracing extensions will be error prone. For now I've left the traceparent transformer in-place but modified the transformer to use the SDK DistributedTracingExtension type rather than the now-deleted traceparent code so that this PR can be unblocked. Lets sync on how we want to handle tracing in the new bindings code-paths and see where I can help with the implementation. |
/unhold |
We have the implementation of extensions for the Event data structure, but nothing with transformers, which are not designed to be "materialized" views of some data, but are direct transformations, while the message is written on the wire. In the SDK we provide some generic transformers (add attribute, add extensions, update extension, ...), but I'm not sure if we want to have these specific transformers... It's something we still didn't discussed |
Fine, i'll get in touch with you |
/lgtm |
# artificially set the SpanId. See pkg/tracing/traceparent.go for more details. | ||
# Produced with: | ||
# git diff origin/master HEAD -- vendor/go.opencensus.io/trace/trace.go > ./hack/set-span-id.patch | ||
git apply ${REPO_ROOT_DIR}/hack/set-span-id.patch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! thanks @ian-mi 🎉
Fixes #2052
Proposed Changes