Provide access to the SchemaURL fields from the OTTL contexts

[bw972]

Component(s)

pkg/ottl

Is your feature request related to a problem? Please describe.

Currently, there is no way to access the SchemaURL fields from the OTTL contexts. Having access to the SchemaURL within the OTTL contexts would enhance the functionality and flexibility of using OTTL.

Describe the solution you'd like

Add the SchemaURL fields to the list of available fields that can be accessed within the OTTL contexts.

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[kernelpanic77]

Hi @TylerHelmuth! Can I take this up ?

[TylerHelmuth]

All yours!

[kernelpanic77]

@TylerHelmuth I am lacking a bit of clarity, on what needs to be done for this issue ? Could you point me to the exact piece of code i should be looking at.

[TylerHelmuth]

Take a look at pkg/ottl/contexts/internal/scope.go. You'll want to add a new case to the switch statement.

[kernelpanic77]

@TylerHelmuth Sorry for my delayed response. Here is my understanding till now.

opentelemetry-collector-contrib/pkg/ottl/contexts/internal/scope.go

Line 19 in 2047ee9

func ScopePathGetSetter[K InstrumentationScopeContext](path ottl.Path[K]) (ottl.GetSetter[K], error) {

I will have to add a field specifically for the "schemaURL" context for the as part of ScopePathGetSetter function.
Here are some doubts I am having.

1. How can I access the schemaURL from the InstrumentationScope ?
2. ScopeLogs, ScopeMetrics and ScopeSpans allow access to the SchemaURL function, should the InstrumentationScope be somehow casted to Scope Logs/Metrics/Spans?

Sorry for my silly questions, I couldn't get my head around the documentation till now 😅

[TylerHelmuth]

Oh I see the problem now, schema_url didn't live in the proto where I thought it did.

This makes it a lot harder to add :/ We'd need to update the TransformContext of each Context to have access to the value, which will be a lot of breaking changes. I don't want to expose all the entire ScopeLogs/ScopeMetrics/ScopeSpan object tho. We also have to provide a way to access both the resource's schemaurl and the scope's.

This problem is no longer easy (you're welcome to continue working on it anyways).

@evan-bradley how do you think we should expose these 2 fields from the proto? OTTL has always followed the proto to the letter, and schema_url lives in a section of the proto hierarchy we've never exposed. I don't really want to make a new contexts for all these scenarios. Could we get away with resource.schema_url and scope.schema_url since the schema_url is the same for all resources and all scopes?