Guidance for conflicting changes for http semantic conventions migration

[lzchen]

In the guidance for migrating semantic conventions it is mentioned that there should be a version of instrumentations that "emit both the old and the stable HTTP and networking attributes, allowing for a seamless transition.". This makes sense for attributes that are not conflicting. Is there guidance on how to apply this "send both old and new" for semantic convention changes that do not pertain to attributes or are conflicting? For example: changing span name.

@trask

[trask]

When OTEL_SEMCONV_STABILITY_OPT_IN=http/dup is selected and there's a conflict between pre-stable and stable HTTP semantic conventions, I think the stable HTTP semantic conventions should win.

[lzchen]

This makes sense to me. As discussed in the maintainer SIG meeting 8/14, if the narrative for this migration plan is "best effort", it would be appropriate to make our best judgement in conflicting cases like this. Personally, I would want to break the user earlier than later so choosing stable sem conv when migrating is conflicting makes sense to me.

[bryannaegele]

@trask since it isn't enumerated in the 1.20 http trace migration plan, I just want to confirm based on this conversation that we want to treat the span name change as a breaking/stable change in addition to the network changes which are enumerated. I'm trying to put together the migration plan for erlang-contrib libs and that was my feeling.

One other clarifying question on this specific topic. We're addressing the changes in 1.20+ as containing the breaking changes (non-stable). The http span name change was introduced in 1.18. I'd like to lump that particular change into the stable/non-stable cutoff since it can have an outsized impact on existing user tooling monitoring off those particular span names.

[trask]

I just want to confirm based on this conversation that we want to treat the span name change as a breaking/stable change in addition to the network changes which are enumerated

yes, this was the intention, can you see if the proposed changes in open-telemetry/semantic-conventions#278 make this clearer from your perspective? thx

[trask]

The http span name change was introduced in 1.18. I'd like to lump that particular change into the stable/non-stable cutoff

yes, this is best to make a single jump, all behind the OTEL_SEMCONV_STABILITY_OPT_IN flag

[bryannaegele]

I just want to confirm based on this conversation that we want to treat the span name change as a breaking/stable change in addition to the network changes which are enumerated

yes, this was the intention, can you see if the proposed changes in open-telemetry/semantic-conventions#278 make this clearer from your perspective? thx

Yes! Those changes would be very helpful.

[austinlparker]

Closed by open-telemetry/semantic-conventions#278