-
Notifications
You must be signed in to change notification settings - Fork 1k
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
otlptracegrpc v2 #5248
Comments
We should only accept a grpc conn for the new package options instead of creating our own. |
Can we also keep DialOptions? It much more convenient, and allows passing many of the other options we support. I think we should keep the v1 of the otlploggrpc exporter consistent with the other signals, unless we plan to release a v2 of the others before we release the v1 of otlploggrpc. |
If we keep |
So, maybe we should just keep the |
I would support keeping WithEndpoint as well in that case. |
@dashpole can you provide some examples here? I'm not sure I follow how passing options via our I'm not opposed to keeping things the way they are in other modules, but I would want to better understand how our API is an improvement before copying it. |
A use case the
The client only solution would mean you need to reproduce all the default/envar stuff on your own. |
With #5247 closed I do not think this issue makes sense. |
The scope of this issue is to create a new
otlptracegrpc
v2 module which would have API similar tootlpmetricgrpc
.Originally posted by @pellared in #2579 (comment)
The text was updated successfully, but these errors were encountered: