Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support all configuration of otlp exporter #774

Open
1 of 10 tasks
TommyCpp opened this issue Apr 6, 2022 · 5 comments · May be fixed by #2465
Open
1 of 10 tasks

Support all configuration of otlp exporter #774

TommyCpp opened this issue Apr 6, 2022 · 5 comments · May be fixed by #2465
Labels
A-common Area:common issues that not related to specific pillar enhancement New feature or request help wanted Good for taking. Extra help will be provided by maintainers/approvers M-exporter-otlp release:allowed-for-stable Changes that can still be added before Stable, but won't require Breaking Interfaces.

Comments

@TommyCpp
Copy link
Contributor

TommyCpp commented Apr 6, 2022

Add support for all configurations in spec

@TommyCpp TommyCpp added enhancement New feature or request help wanted Good for taking. Extra help will be provided by maintainers/approvers A-common Area:common issues that not related to specific pillar labels Apr 6, 2022
@TylerHelmuth
Copy link
Member

Does opentelemtry-otlp already add the signal path automatically when using gRPC?

@TommyCpp
Copy link
Contributor Author

Does opentelemtry-otlp already add the signal path automatically when using gRPC?

gRPC doesn't really require a path, right? The service/client stub should take care of that

@TylerHelmuth
Copy link
Member

You're totally right, my bad

@atanunq
Copy link
Contributor

atanunq commented Jun 9, 2022

Hey all! I'm interested in trying to implement one of the items in the list as a way to get more familiar with the repository. Certificate file looks like a good candidate. However, I am struggling with seeing the configuration flow in general. Could you please share some pointers on how to go about implementing it?

For example, I am testing locally with tonic. I managed to connect over TLS to a collector using new_exporter().tonic().with_tls_config(ClientTlsConfig::new(...)). However, this is tonic-specific. Based on the linked spec above, I assume the new way of configuring should be taken into account within all protocols (i.e different third party crates). Is that correct?

If that is the case, the ExportConfig struct looks like a good place to add it. Then, though, ExportConfig and TonicConfig.tls_config may have different values and one needs to take precedence over the other. How/where would that be decided?

I do hope any of that makes sense. Thanks!

@hdost hdost added release:required-for-stable Must be resolved before GA release, or nice to have before GA. M-exporter-otlp release:allowed-for-stable Changes that can still be added before Stable, but won't require Breaking Interfaces. and removed release:required-for-stable Must be resolved before GA release, or nice to have before GA. labels Feb 21, 2024
@hdost hdost added this to the Tracing OTLP Exporter Stable milestone Feb 21, 2024
@hdost
Copy link
Contributor

hdost commented Feb 21, 2024

Related #984

@jvanz jvanz linked a pull request Dec 23, 2024 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-common Area:common issues that not related to specific pillar enhancement New feature or request help wanted Good for taking. Extra help will be provided by maintainers/approvers M-exporter-otlp release:allowed-for-stable Changes that can still be added before Stable, but won't require Breaking Interfaces.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants