Semantic convention translation processor

[Aneurysm9]

Is your feature request related to a problem? Please describe.
We need a processor that can perform the translation between semantic convention schema versions outlined in OTEP-152.

Describe the solution you'd like
A processor should be implemented that can be configured with a target schema version. The processor would then use published schema translation information to process all incoming attributes that are associated with a schema version other than the target schema until they have been converted to the target schema.

Describe alternatives you've considered
Alternately, a library that can perform this translation could be created and then integrated in the existing resource and attribute processors.

[ericmustin]

hello frens, just checking in on this, we're looking into adding schemaUrl support for opentelemetry-ruby, and wanted to see where the rest of the components described in OTEP-152 stand. As far as I can tell there's nothing in prog on a 'schemaUrl transformation' type processor at the moment? Totally fine, just want to understand where I can track work here, or which SIG mtgs would be the right place to discuss this. Otel-collector sig perhaps?

edit: for anyone following along, looks like some very rough prototyping of a processor can be found here , and is discussed in the OTEP-152 Performance Impact section

[Aneurysm9]

Tigran has started work on a parser for schema instances at open-telemetry/opentelemetry-go#2267. I think this would be the first step toward building a translation library that would be usable in both the Go SDK and the collector. When we have that in place building this processor should be relatively straightforward.

[ericmustin]

have a rough implementation up in ruby (for ref: open-telemetry/opentelemetry-ruby#979, any reviews/feedback super welcome :) ) .

It's actually a bit unclear to me whether we should be building out the sort've "parser for schema instances" support in language clients too? Like is opentelemetry-go just a nice home for this parser or is the plan that this translation/conversion ought to eventually have an option to occur in a language specific otel library, via some sort of not-yet-defined processor? (since some vendors don't rely on an otel collector as part of their export pipeline, or the environment itself may not permit a collector, ala client-side js/mobile instrumentation, or serverless/a managed PaaS)

[Aneurysm9]

If language clients are going to support migrating resource attributes to different schema versions, which seems likely to be necessary to support merging resources with different schemas, then I think each language will need to have an implementation of a schema parser and translation processor.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.