Most flexibility provides gRPC connection

[pengweiqhca]

Fixes #4813

Changes

Add OtlpExporterOptions.HttpHandlerFactory property to get a HttpHandler.

Merge requirement checklist

• CONTRIBUTING guidelines followed (nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[vishweshbankwar]

@pengweiqhca Thanks for the PR. We are currently working on releasing 1.6.0. We will review the issue and PR sometime next week. Thanks for your patience.

[AB027PS]

This also fixes #4771.

[vishweshbankwar]

@pengweiqhca Could you please provide more detailed steps for repro on this (Please update the issue)? Once we have a repro, we will then explore the possible solution.

[jviau]

I'd recommend not exposing HTTP at all in the options. Instead allow for a Grpc.Core.Api.CallInvoker to be provided. This will work with both Grpc.Net.Client as well as Grpc.Core. No if-def'ing needed. It will give the most flexibility with how a user provides their desired gRPC connection - including creating a call invoker with all the custom HttpClient / HttpHandler under the hood as needed.

[pengweiqhca]

@vishweshbankwar I has change the repro.
@jviau Grpc.Core.Api.CallInvoker is a good idea, it is possible for log, trace, and metrics to use the same Grpc channel.

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[cvi-mft]

Why was this closed?

[alexander-kucherov]

Why this PR was closed? I also need this changes

[alexander-kucherov]

Any news ?

[CodeBlanch]

@alexander-kucherov We're currently working to remove the grpc library dependencies from the OtlpExporter. This particular API won't be possible to expose in that design. I think the best thing to do is open an issue with what you want to do, what the current blockers are. We can work to expose something once the new design is ready (which should be soon: https://github.com/open-telemetry/opentelemetry-dotnet/milestone/44).

AFAIK @rajkumar-rangaraj's plan at the moment is everything will use HttpClient so it may be possible to do what you need via the existing APIs/extension points once the work is complete?