-
Notifications
You must be signed in to change notification settings - Fork 635
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
Added experimental HTTP backpropagators #1762
Conversation
4febe52
to
7b11971
Compare
48247ca
to
3ff4d24
Compare
3ff4d24
to
f6b04c4
Compare
This looks clean. Does it become part api once it is moved from experimental to stable or it is something remains with instrumentation package? |
I think it'll remain in instrumentation package until the trace response proposal is merged into W3C and proposed in Otel. |
@aabmass @lonewolf3739 PTAL when you can. Thanks. |
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Show resolved
Hide resolved
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.
LGTM
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Show resolved
Hide resolved
ff3ee9c
to
bedd0c6
Compare
_BACK_PROPAGATOR = None | ||
|
||
|
||
def get_global_back_propagator(): |
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.
I feel like instrumentation_propagator
should be a better name, considering the path of this module. Also, do we really need these get
and set
methods? They give the exact same "protection" and namespacing as not having them at all.
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.
I can change but it's already under instrumentation package so the import path would become opentelemetry.instrumentation.instrumentation_propagator
which seems redundant and causes unnecessary stutter.
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.
What I mean is that using back
here is confusing. This is a propagator that is associated with instrumentation
, right?
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.
What do you think about keeping these get
and set
methods, @owais?
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.
@ocelotl not necessarily, its called back propagator because it injects context into the response headers to propagate context backward to the caller. I think Owais has added it to the instrumentation package just because its a convenient place that instrumentation packages already have access to. Eventually, we would move this to opentelemetry-api
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.
And I believe the get/set are added here to keep a similar API to set_global_textmap()
, set_tracer_provider()
etc. ?
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Outdated
Show resolved
Hide resolved
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Show resolved
Hide resolved
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Outdated
Show resolved
Hide resolved
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Outdated
Show resolved
Hide resolved
class TraceResponsePropagator: | ||
"""Experimental propagator that injects tracecontext into HTTP responses.""" | ||
|
||
_HEADER_NAME = "traceresponse" |
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.
Nit: this is a class attribute, not a module-level constant, it should be lower cased.
|
||
_HEADER_NAME = "traceresponse" | ||
|
||
def _format_header(self, span_context): # pylint: disable=no-self-use |
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.
I would suggest to handle this with an ABC and static and abstract methods:
from abc import ABC, abstractmethod
class Parent(ABC):
@staticmethod
@abstractmethod
def method(arg):
pass
class Child(Parent):
@staticmethod
def method(arg):
print(arg)
Child().method(4)
class Child(Parent):
@staticmethod
def mathod(arg):
print(arg)
Child().mathod(4)
4
Traceback (most recent call last):
File "tato.py", line 26, in <module>
Child().mathod(4)
TypeError: Can't instantiate abstract class Child with abstract methods method
d502b0f
to
cb5c78b
Compare
092dcf3
to
e23dec1
Compare
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Outdated
Show resolved
Hide resolved
_BACK_PROPAGATOR = None | ||
|
||
|
||
def get_global_back_propagator(): |
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.
What I mean is that using back
here is confusing. This is a propagator that is associated with instrumentation
, right?
_BACK_PROPAGATOR = None | ||
|
||
|
||
def get_global_back_propagator(): |
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.
What do you think about keeping these get
and set
methods, @owais?
|
||
|
||
class ResponsePropagator(ABC): | ||
@abstractmethod |
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.
This feels like a class attribute actually. If you want to still use a method to access it, it should be a property:
class Parent:
_the_attribute = None
@property
def _attribute(self):
return self._the_attribute
class Child(Parent):
_the_attribute = "child_attribute"
print(Child()._attribute)
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.
OK. Will make the change shortly.
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Outdated
Show resolved
Hide resolved
def _format_header( | ||
self, span_context | ||
) -> str: # pylint: disable=no-self-use | ||
return 'traceparent;desc="00-{trace_id}-{span_id}-{:02x}"'.format( |
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.
I guess it comes from this?
You're right. Even this implementation is calling it either "back propagator" or "response propagator". Agree we should pick one. I don't have a strong preference. Which one do you suggest to use? @ocelotl |
They kind of are. In the sense that only instrumentation is using them today and we don't document them for users but technically it's not tried to instrumentations at all. Users can use it in their manual code just like regular propagators. |
I prefer response, it is more specific. |
I mean the |
73a603b
to
af7aa98
Compare
@ocelotl Ah. I feel the functions are much more nicer to use and are consistent with how other global objects are set by API (provider, propagators). I don't think they really add any harm. I can add some type checking or safety later if you'd like. |
opentelemetry-instrumentation/src/opentelemetry/instrumentation/propagators.py
Outdated
Show resolved
Hide resolved
1eb8c0d
to
7fba05a
Compare
bf0c681
to
880becc
Compare
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.
This should work, approving. Just a question remains regarding ABC
s and extract
.
self._func(carrier, key, value) | ||
|
||
|
||
class ResponsePropagator(ABC): |
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.
Approving, but just a question: don't we have already an ABC
for propagators? I understand that these are "back" propagators (and they propagate in only one way, if I understand correctly), but may there be any situation where extract
also needs to be defined?
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.
These are generally for web servers to respond with. May be someone uses Python compiled to JS in browser extract would be helpful. For any other type of client, the client is in full control and can start a trace before sending requests out. Only JS in browser is unable to do that as browser starts first request with JS having no control over it.
But questions like this is exactly why adding it as a propagator made more sense so we can flesh out how this should work in some time and may be provide other SIGs with a reference implementation and feedback for spec.
@ocelotl |
_RESPONSE_PROPAGATOR = propagator | ||
|
||
|
||
class DictHeaderSetter: |
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.
Similarly to normal propagators, shouldn't Setter
be an ABC so others can create their own Setter
s?
default_setter = DictHeaderSetter() | ||
|
||
|
||
class FuncSetter: |
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.
Can we get some guidance (maybe some comments) on when FuncSetter
should be used vs Setter
?
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.
Added doc string that describes intention and usage.
05973b7
to
879aba3
Compare
The experimental back propagators inject trace response headers into HTTP responses. These are meant to be used by instrumentations and are not considered stable.
879aba3
to
18f8ac2
Compare
18f8ac2
to
8565c64
Compare
Description
The experimental back propagators inject trace response headers into
HTTP responses. These are meant to be used by instrumentations and are
not considered stable.
Contrib PRs that need this feature: open-telemetry/opentelemetry-python-contrib#436
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: