[GrpcNetClient] Clarify impact to SuppressDownstreamInstrumentation

[alanwest]

We should probably decide what we're actually going to do with SuppressDownstreamInstrumentation, but for the purpose of getting the next release out, I just wanted to clean up our advisory.

[reyang]

We should probably decide what we're actually going to do with SuppressDownstreamInstrumentation, but for the purpose of getting the next release out, I just wanted to clean up our advisory.

Would this PR description help on the direction? #960 (comment)

[alanwest]

Would this PR description help on the direction?

Yes, this is an interesting thought to consider. I believe what you're saying is there's no reason instrumentation needs an SDK dependency to check otel.suppress_instrumentation using RuntimeContext from OpenTelemetry.Api directly. We'd add the check back in the HTTP instrumentation as well.

Does anyone have strong feelings that we pursue this fix prior to releasing 1.7.1 today (#5322)? (@utpilla, @CodeBlanch, @vishweshbankwar)

My opinion is, since this breaking change was introduced last November that we merge this PR with a clear advisory, release 1.7.1 today, and then follow up with this idea.

[reyang]

Would this PR description help on the direction?

Yes, this is an interesting thought to consider. I believe what you're saying is there's no reason instrumentation needs an SDK dependency to check otel.suppress_instrumentation using RuntimeContext from OpenTelemetry.Api directly. We'd add the check back in the HTTP instrumentation as well.

Correct, it's just a convention/suggestion (instead of a promise) that anyone can choose to follow (e.g. if there is another telemetry SDK, it can choose to respect this flag as well).

[utpilla]

Does anyone have strong feelings that we pursue this fix prior to releasing 1.7.1 today (#5322)?

No.

My opinion is, since this breaking change was introduced last November that we merge this PR with a clear advisory, release 1.7.1 today, and then follow up with this idea.

I'm fine with that.

[vishweshbankwar]

Would this PR description help on the direction?

Yes, this is an interesting thought to consider. I believe what you're saying is there's no reason instrumentation needs an SDK dependency to check otel.suppress_instrumentation using RuntimeContext from OpenTelemetry.Api directly. We'd add the check back in the HTTP instrumentation as well.

Correct, it's just a convention/suggestion (instead of a promise) that anyone can choose to follow (e.g. if there is another telemetry SDK, it can choose to respect this flag as well).

Would this PR description help on the direction?

Yes, this is an interesting thought to consider. I believe what you're saying is there's no reason instrumentation needs an SDK dependency to check otel.suppress_instrumentation using RuntimeContext from OpenTelemetry.Api directly. We'd add the check back in the HTTP instrumentation as well.

Correct, it's just a convention/suggestion (instead of a promise) that anyone can choose to follow (e.g. if there is another telemetry SDK, it can choose to respect this flag as well).

I believe this(#960 (comment)) is a good option to consider for offering SuppressDownstreamInstrumentation as an experimental feature. Experimental because we also need to think about the case when instrumentation will be done natively by HttpClient (starting with .NET 9.0) and eventually by Grpc.Net.Client as well.

I am good with going ahead with the release for now.