-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add initial implementation of pdatagrcp #3231
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one nit
@bogdandrutu Please add some notes in the PR description that clarify why this change is needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idea LGTM, just one minor question.
// LogsClient is the client API for OTLP-GRPC Logs service. | ||
// | ||
// For semantics around ctx use and closing/ending streaming RPCs, please refer to https://godoc.org/google.golang.org/grpc#ClientConn.NewStream. | ||
type LogsClient interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need an interface? I assume there will be only one implementation ever. Should we simply, delete the interface and just have the struct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can either expose the struct or the interface. I think exposing the interface is more future proof, because we can offer alternative implementations in the future. Not a big thing though, so if you feel strong I can change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a strong opinion. Works either way.
This is needed because if we split pdata, we will nolonger be able to depend on the InternalRep or generated proto classes (raw, grpc). The pdatagrcp will eventually be public once we stabilize the API. The API in the pdatagrcp package is inspired from the grpc generated classes and redirects all calls to the generated classes. Some simple renames: * TraceService[Client|Server] -> Traces[Client|Server] * MetricsService[Client|Server] -> Metrics[Client|Server] * LogsService[Client|Server] -> Logs[Client|Server] Other changes: * Replace usages of grpc generated classes in otlpexporter to excercise this new package. * Left some TODOs for the moment until this package is used more to determine the right API. Signed-off-by: Bogdan Drutu <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, up to you if you want to do anything about the remaining comments.
// LogsClient is the client API for OTLP-GRPC Logs service. | ||
// | ||
// For semantics around ctx use and closing/ending streaming RPCs, please refer to https://godoc.org/google.golang.org/grpc#ClientConn.NewStream. | ||
type LogsClient interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a strong opinion. Works either way.
Signed-off-by: Bogdan Drutu <[email protected]>
* Add initial implementation of pdatagrcp This is needed because if we split pdata, we will nolonger be able to depend on the InternalRep or generated proto classes (raw, grpc). The pdatagrcp will eventually be public once we stabilize the API. The API in the pdatagrcp package is inspired from the grpc generated classes and redirects all calls to the generated classes. Some simple renames: * TraceService[Client|Server] -> Traces[Client|Server] * MetricsService[Client|Server] -> Metrics[Client|Server] * LogsService[Client|Server] -> Logs[Client|Server] Other changes: * Replace usages of grpc generated classes in otlpexporter to excercise this new package. * Left some TODOs for the moment until this package is used more to determine the right API. Signed-off-by: Bogdan Drutu <[email protected]> * Add details for the TODOs left Signed-off-by: Bogdan Drutu <[email protected]>
This is needed because if we split pdata, we will nolonger be able to depend on the InternalRep or generated proto classes (raw, grpc).
The pdatagrcp will eventually be public once we stabilize the API.
The API in the pdatagrcp package is inspired from the grpc generated classes and redirects all calls to the generated classes. Some simple renames:
Other changes:
Signed-off-by: Bogdan Drutu [email protected]
Updates #3104