Conversation
| Default span name is the HTTP method and URL path, or just the method. | ||
| https://github.com/open-telemetry/opentelemetry-specification/pull/3165 | ||
| https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/http/#name | ||
|
|
There was a problem hiding this comment.
This seems like a potential breaking change:
open-telemetry/opentelemetry-python-contrib#1759
There was a problem hiding this comment.
Checking results of requests and dependencies. All columns match. So, I think we can consider this change to be okay.
Matching requests.csv
Matching dependencies.csv
.../azure/monitor/opentelemetry/_vendor/v0_40b0/opentelemetry/instrumentation/dbapi/__init__.py
Outdated
Show resolved
Hide resolved
...y/azure/monitor/opentelemetry/_vendor/v0_40b0/opentelemetry/instrumentation/asgi/__init__.py
Outdated
Show resolved
Hide resolved
...azure/monitor/opentelemetry/_vendor/v0_40b0/opentelemetry/instrumentation/django/__init__.py
Outdated
Show resolved
Hide resolved
...zure/monitor/opentelemetry/_vendor/v0_40b0/opentelemetry/instrumentation/fastapi/__init__.py
Outdated
Show resolved
Hide resolved
|
Any reason we want to support 0.40b0 so soon? Are you planning on vendoring everytime there's a new release of the instrumentations? |
I guess being behind on vendoring doesn't block Cxs like being behind on the sdk/api. So, we can hold off. |
|
I think the key is to have an understanding between us and the customers. Should we only update it when there's a release, or should it be update only if there are big/breaking/feature changes? I think we can start with the latter and if there is sufficient demand for latest features we can change our process. |
* Unpin OTel version * ~= for exporter
|
Azure SDK Version: Azure/azure-sdk-for-python#31719 |
|
Closing in favor of unvendoring: Azure/azure-sdk-for-python#31744 |
2 participants
No description provided.