HTTP SemConv transition plan is not extensible

[dyladan]

The HTTP SemConv transition plan defines an environment variable with potential values http, http/dup, etc. It is my understanding that the plans for future semconv areas like messaging will add additional possible values to this environment variable ( e.g. OTEL_SEMCONV_STABILITY_OPT_IN =http/dup/messaging) source.

After the transition plan merged, it was pointed out to me by @Flarna that the variable requires a predefined method for multiple values such as comma-separated values. Otherwise an implementation which simply checks env.OTEL_SEMCONV_STABILITY_OPT_IN == "http" or uses a switch/case will be broken in the case that multiple values exist as in the example above.

Action items:

• Document in specification/configuration/sdk-environment-variables.md
• Add explicit comma separated format
  • Alternatively: explicitly decide we are not going to extend it in the future

/cc @trask

[dyladan]

It should also be documented in specification/configuration/sdk-environment-variables.md

[mateuszrzeszutek]

Wasn't that exactly the point behind this env var?
I was under the impression that this was a one-time exercise done only because the HTTP semconv and instrumentations are so widespread, and that we're not going to repeat that approach when stabilizing other conventions (like messaging or rpc).

[dyladan]

Wasn't that exactly the point behind this env var?
I was under the impression that this was a one-time exercise done only because the HTTP semconv and instrumentations are so widespread, and that we're not going to repeat that approach when stabilizing other conventions (like messaging or rpc).

If you click through the link in the OP you will see that may not be the case.

[trask]

I was under the impression that this was a one-time exercise done only because the HTTP semconv and instrumentations are so widespread, and that we're not going to repeat that approach when stabilizing other conventions (like messaging or rpc).

this was an earlier plan, but it changed last week to support future csv values

Otherwise an implementation which simply checks env.OTEL_SEMCONV_STABILITY_OPT_IN == "http" or uses a switch/case will be broken in the case that multiple values exist as in the example above.

this is a great point, I'll send a PR to fix this

[trask]

Action items:

• Document in specification/configuration/sdk-environment-variables.md

I'm not sure about this since it's not an SDK environment variable

• Add explicit comma separated format

I've sent #3492 👍

[mateuszrzeszutek]

If this is supposed to be extensible, should we remove the

• SHOULD drop the environment variable in the next major version (stable
  next major version SHOULD NOT be released prior to October 1, 2023).

part then? I am not convinced that we can stabilize (let alone implement) messaging semconv before October.

Also, what's going to happen when we do release a 2.0 instrumentation package? If the env var stays, should the http http/dup options be removed?

[dyladan]

If this is supposed to be extensible, should we remove the

• SHOULD drop the environment variable in the next major version (stable
  next major version SHOULD NOT be released prior to October 1, 2023).

part then? I am not convinced that we can stabilize (let alone implement) messaging semconv before October.

Not just messaging. This will likely be an ongoing concern for a long time as we stabilize all the semconv

Also, what's going to happen when we do release a 2.0 instrumentation package? If the env var stays, should the http http/dup options be removed?

I would think so

[mateuszrzeszutek]

(I know that #3443 has my approval on it, but I approved the previous version of that warning)

@trask I think that warning (and env var) as it is now is rather confusing for instrumentation maintainers, as it mixes several the HTTP-specific concerns and the general usage of the env var.

• SHOULD maintain (security patching at a minimum) the existing major version
  for at least six months after it starts emitting both sets of attributes.
• SHOULD drop the environment variable in the next major version (stable
  next major version SHOULD NOT be released prior to October 1, 2023).

I think these two points should be rephrased so that they only apply to the http http/dup values, not the env var itself. Perhaps the v1.20.0 warning should also apply to chosen values, not the env var itself (as new to-be-stable semconvs will set different support dates/releases)