Added experimental HTTP backpropagators

[owais]

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.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

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

• Unit tests
• Manual testing

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[srikanthccv]

This looks clean. Does it become part api once it is moved from experimental to stable or it is something remains with instrumentation package?

[owais]

I think it'll remain in instrumentation package until the trace response proposal is merged into W3C and proposed in Otel.

[owais]

@aabmass @lonewolf3739 PTAL when you can. Thanks.

[aabmass]

LGTM

[ocelotl]

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.

[owais]

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.

[ocelotl]

What I mean is that using back here is confusing. This is a propagator that is associated with instrumentation, right?

[ocelotl]

What do you think about keeping these get and set methods, @owais?

[aabmass]

@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

[aabmass]

And I believe the get/set are added here to keep a similar API to set_global_textmap(), set_tracer_provider() etc. ?

[ocelotl]

Nit: this is a class attribute, not a module-level constant, it should be lower cased.

[ocelotl]

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

[ocelotl]

What I mean is that using back here is confusing. This is a propagator that is associated with instrumentation, right?

[ocelotl]

What do you think about keeping these get and set methods, @owais?

[ocelotl]

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)

[owais]

OK. Will make the change shortly.

[ocelotl]

I guess it comes from this?

[owais]

What I mean is that using back here is confusing. This is a propagator that is associated with instrumentation, right?

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

[owais]

What do you think about keeping these get and set methods, @owais?

@ocelotl Sorry, I'm not following. Could you please elaborate?

(for some reason I'm not able to comment in-line on some of your comments).

[owais]

What I mean is that using back here is confusing. This is a propagator that is associated with instrumentation, right?

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.

[ocelotl]

What I mean is that using back here is confusing. This is a propagator that is associated with instrumentation, right?

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

I prefer response, it is more specific.

[ocelotl]

What do you think about keeping these get and set methods, @owais?

@ocelotl Sorry, I'm not following. Could you please elaborate?

(for some reason I'm not able to comment in-line on some of your comments).

I mean the get_global_back_propagator and set_global_back_propagator which don't actually provide any protection to the propagator object, so simply using a module-level variable is the same thing with two less methods.

[owais]

I mean the get_global_back_propagator and set_global_back_propagator which don't actually provide any protection to the propagator object, so simply using a module-level variable is the same thing with two less methods.

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

[owais]

@ocelotl @lzchen

• Updated to call use "response" instead of "back".
• Removed "ServerTiming" propagator implementation.

[ocelotl]

This should work, approving. Just a question remains regarding ABCs and extract.

[ocelotl]

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?

[owais]

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.

[lzchen]

@ocelotl
Are your questions addressed?

[lzchen]

Similarly to normal propagators, shouldn't Setter be an ABC so others can create their own Setter s?

[lzchen]

Can we get some guidance (maybe some comments) on when FuncSetter should be used vs Setter?

[owais]

Added doc string that describes intention and usage.