OTEP: Span Event API deprecation plan #4430
Conversation
e08d0b4 to
0d0204a
Compare
e09c0f3 to
7c9ed89
Compare
7c9ed89 to
db7164d
Compare
Co-authored-by: Liudmila Molkova <limolkova@microsoft.com>
Co-authored-by: Robert Pająk <pellared@hotmail.com>
Co-authored-by: Robert Pająk <pellared@hotmail.com>
There was a problem hiding this comment.
Thank you @trask. Left some comments.
TLDR of my feedback is that:
- Both the OTEL Collector and SDKs should be able to act as a backward compatibility shim with relatively little configuration or negative impact.
- A decision needs to be made as to what the story is for users that currently use only tracing and have no plans to ingest logs.
Co-authored-by: Robert Pająk <pellared@hotmail.com>
|
copying folks who commented on this PR but haven't approved it yet: please let us know if you have any further concerns, otherwise we will plan to merge it by end of the week, thanks! |
Would be curious about this point? What was the compromise or the thing to be massaged in the near future? |
|
@carlosalberto open-telemetry/opentelemetry-python#4561 Also I believe the intent is to store the exception type and message of span-ending exceptions directly on the span as attributes, but not the stacktrace. |
|
Thanks @alexmojaki - LGTM |
I like this direction, but we'll need to work it out in #4333 |
May 2025 Release. ### Context - Drop reference to binary `Propagator`. ([#4490](#4490)) ### Logs - Add optional `Event Name` parameter to `Logger.Enabled` and `LogRecordProcessor.Enabled`. ([#4489](#4489)) ### Resource - Add experimental resource detector name. ([#4461](#4461)) ### OTEPs - OTEP: Span Event API deprecation plan. ([#4430](#4430))
Based on number of comments in related PRs and issues, please go to the "Files changed" tab and add your comment somewhere there (instead of leaving the comment directly on the conversation), so that we can have threaded discussions. Thank you ❤️.
Related to #4333, #4393, #4429, #4414