Http instrumentation libraries stable release plan

[vishweshbankwar]

open-telemetry/opentelemetry-specification#3443 lays out the detailed plan for stabilizing the http instrumentation libraries.

PRs that include major changes
open-telemetry/opentelemetry-specification#3402
open-telemetry/opentelemetry-specification#3426
open-telemetry/opentelemetry-specification#3355

For .NET, we will proceed as follows

1. Update the following instrumentation libraries to look up OTEL_SEMCONV_STABILITY_OPT_IN environment variable and set the attributes as per the values specified in spec.

• OpenTelemetry.Instrumentation.AspNetCore
• OpenTelemetry.Instrumentation.Http
• OpenTelemetry.Instrumentation.SqlClient
• OpenTelemetry.Instrumentation.GrpcNetClient

Note: The change impacts all the above libraries due to updates in networking attributes open-telemetry/opentelemetry-specification#3402

2. Release the RC version with the above mentioned changes.

3. Drop OTEL_SEMCONV_STABILITY_OPT_IN environment variable from OpenTelemetry.Instrumentation.AspNetCore and OpenTelemetry.Instrumentation.Http in the final RC version.

Note: Other libraries should continue to look up the environment variable.

4. Release stable 1.0.0 version of OpenTelemetry.Instrumentation.AspNetCore and OpenTelemetry.Instrumentation.Http.

[TimothyMothra]

FYI: this doc is useful for tracking changes to the conventions:
https://github.com/open-telemetry/opentelemetry-specification/blob/v1.22.0/schemas/1.21.0

[TimothyMothra]

FYI.
Semantic-Conventions repo is readying their first release. The version will be v1.21.0. No ETA because they're building out the processes.
https://github.com/open-telemetry/semantic-conventions/blob/df8e53054147acf49918582bd446d0f524170071/CHANGELOG.md

Trask advised that we should link to "main" for now.

I will create a new PR to correct everything that merged already.

[danelson]

Are there any plans to publish the schema url? Is that something that would happen here or in the runtime? Consuming this data from many different language SDKs across different versions of those SDKs becomes an issue when querying data in various backends. I would love to start using the schema processor to help alleviate this but the schema url needs to be available.

[cijothomas]

Are there any plans to publish the schema url? Is that something that would happen here or in the runtime? Consuming this data from many different language SDKs across different versions of those SDKs becomes an issue when querying data in various backends. I would love to start using the schema processor to help alleviate this but the schema url needs to be available.

Not possible until this is done : #2417