Contrib tests expect an object like log.log_record returned in log_exporter.get_finished_logs()
I can update contrib tests for this breaking issue, let me know your thoughts

What if instead of removingLogData, we removeLogRecord from the SDK, and updateLogData to have 3 fields: the API LogRecord, theresource, and theinstrumentation_scope..

I don't think we need aLogRecord in both the API and the SDK, when they are exactly the same except for 2 additional fields on the SDK version (resource andinstrumentation_scope)..

This way we don't need to update 2 classes every time a change is made to the log data structure.

Also I think our implementation is confusing the 2 classes in a bunch of places maybe because they are named the same. For example I thinkLogger.emit should be taking an APILogRecord instead of an SDK one. We tell instrumentations to use the APILogRecord, and instrumentations therfore callLogger.emit with the API LogRecord, the SDK implementation should be addinginstrumentation_scope andresource (toLogData) and then forward it along..

@DylanRussell we can also call it SDKLogRecord like Javascripthttps://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/sdk-logs/src/index.ts#L24

Yeah I think i'm OK with that name too. But what do you think of it being just the 3 fields I mentioned above ? And switching Logger.emit in the SDK to take the API LogRecord and then create the SDK LogRecord and attach instrumentation_scope/resource to it..

That looks to be what javascript is doing too:

https://github.com/open-telemetry/opentelemetry-js/blob/99dde7786f52d8d7e3d080a0a69b9685104c29e2/experimental/packages/sdk-logs/src/Logger.ts#L42

@DylanRussell updated, still having SDKLogRecord inheriting API LogRecord, having the API LogRecord as an attribute feels really weird to me, I think it could cause more confusion an issues than solving them, let me know what you think.

@open-telemetry/python-maintainers this is definitely a big breaking change, do we want to use another branch to group the Logs updates together?, we discussed this last week SIG meeting, but trying to understand what is the best way to move forward here.

In my opinion just have SdkLogRecord with a ApiLogRecord attribute, it should not inherit from it at all now.. We don't need another class with all the same attributes.

We just need a small wrapper class..

Logger.emit should accept anApiLogRecord (not an SDK log record), it should then create theSdkLogRecord with thelogger's instrumentation_scope and resource.

AndLoggingHandler._translate should produce anApiLogRecord..

Looks like some instrumentations fail w/ this change (https://github.com/open-telemetry/opentelemetry-python-contrib/blob/f20fa77ad59d90aae4978ae28cb1a98b12fbb959/instrumentation-genai/opentelemetry-instrumentation-vertexai/tests/test_function_calling.py#L4 -- this instrumentation is accessinglog_data.log_record.. If you keeplog_record as an attribute that might pass)

I know at one of the spec meetings we agreed it was a good idea to make a bunch of the breaking changes in one release.. Do we want to add the@Deprecation wrappers to some of these things first (ex: onLogData and the SDKLogRecord), wait a release, then do it, or just go ahead and make the change ?

This PR should be ready for another look now, failing tests are about commit mismatch and actual check of breaking changes that is accurate in this case

I've tried running pyright in this branch:

diff --git a/pyproject.toml b/pyproject.tomlindex 856d9da57..708409eb3 100644--- a/pyproject.toml+++ b/pyproject.toml@@ -111,7 +111,7 @@ include = [ exclude = [   "opentelemetry-sdk/tests",   "opentelemetry-sdk/src/opentelemetry/sdk/_events",-  "opentelemetry-sdk/src/opentelemetry/sdk/_logs",+  #"opentelemetry-sdk/src/opentelemetry/sdk/_logs",   "opentelemetry-sdk/src/opentelemetry/sdk/error_handler",   "opentelemetry-sdk/src/opentelemetry/sdk/metrics",   "opentelemetry-sdk/src/opentelemetry/sdk/trace/export",

And got a bunch of errors related to *LogRecord classes:

  /home/rm/src/opentelemetry-python/opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/__init__.py:608:22 - error: Type "ReadWriteLogRecord" is not assignable to declared type "LogRecord"    "ReadWriteLogRecord" is not assignable to "LogRecord" (reportAssignmentType)  /home/rm/src/opentelemetry-python/opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/__init__.py:613:50 - error: Argument of type "LogRecord | <subclass of LogRecord and ReadWriteLogRecord>" cannot be assigned to parameter "log_record" of type "ReadWriteLogRecord" in function "on_emit"    Type "LogRecord | <subclass of LogRecord and ReadWriteLogRecord>" is not assignable to type "ReadWriteLogRecord"      "LogRecord" is not assignable to "ReadWriteLogRecord" (reportArgumentType)  /home/rm/src/opentelemetry-python/opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/export/__init__.py:96:35 - error: Cannot access attribute "to_json" for class "ReadableLogRecord"    Attribute "to_json" is unknown (reportAttributeAccessIssue)  /home/rm/src/opentelemetry-python/opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/export/__init__.py:129:26 - error: Argument of type "Resource | None" cannot be assigned to parameter "resource" of type "Resource" in function "__init__"    Type "Resource | None" is not assignable to type "Resource"      "None" is not assignable to "Resource" (reportArgumentType)  /home/rm/src/opentelemetry-python/opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/export/__init__.py:204:22 - error: Argument of type "Resource | None" cannot be assigned to parameter "resource" of type "Resource" in function "__init__"    Type "Resource | None" is not assignable to type "Resource"      "None" is not assignable to "Resource" (reportArgumentType)

Some may predate your changes but maybe worth to fix so we don't have to change typing later, some looks like we typed a RedableLogRecord but we are using methods only available to ReadWriteLogRecord.
There's a bunch of other errors unrelated to this inside the logs module that may be nice to fix as well so we can enable type checking.

@xrmx pyright should be good now, I always get "Git operation failed" errors randomly in some test, not sure if there is something I can do to fix that

@xrmx pyright should be good now, I always get "Git operation failed" errors randomly in some test, not sure if there is something I can do to fix that

thanks! Unfortunately you cannot do anything about the transient git errors