aligning opentracing.tracer with servicer_context.tracer

[niryarden]

When I use the python-grpc module on a server, the only way I can access the active span in the code is using the RPC context (that includes the span). That's because the RPC context is the only place that keeps track of the scope manager and the current active span. However, if I'm not mistaken, it's a pretty common pattern that the general opentracing module would be aligned with the tracing activity that the framework-specific module is generating.

why?

1. this would enable me to access the active span anywhere my the code by calling opentracing.tracer.active_span without being required to pass the context to every function I call from the RPC.
2. that would enable me to generate more complex spans activity on top of the activity the python-grpc module generates. (for example, opening and closing spans for child functions of the RPC).
3. that would enable third-party software products that uses or communicates with the opentracing data to be able to do so, by importing opentracing and using it anywhere it wants. (That's actually how I bumped into this issue, my company's agent is accessing the server's tracing data for advanced features)è

how?
#35

[harshita-meena]

Hi I was wondering if there is any progress on this, the PR I see is not merged yet. It is possible to get the current context without propagating in Flask Tracing (it inherits opencensus tracing so it has the span active but not in grpc tracing. The solution proposed by Nir seems doable. Please let me know if there is another way to activate a span. I am having issue adding tracing to a service that has both rest & grpc endpoints.

[niryarden]

@harshita-meena unfortunately, this repo does not seem to be maintained.
The solution I went with is forking it and using the fork for my needs. It's far from ideal, but worked for me.
feel free do the same:
github.com/Rookout/python-grpc

[harshita-meena]

Thanks Nir, sadly it will be difficult for me to do that because I am working on another open source repo (seldon-core) that installs this library. It will be very difficult to convince developers of the custom change. THankyou for your suggestion! I now know why i was not able to connect my child traces with parent trace with grpc requests. (Because we don't activate it, so opencensus instrumentation can't fetch the current context.)

[harshita-meena]

In fact i see start_span everywhere in _server & _client code, they should probably use start_active_span on the tracer ?