-
Notifications
You must be signed in to change notification settings - Fork 440
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
Explicitly set Service Port Protocol for Jaeger Receivers #117
Conversation
I have now signed the CLA, but I don't know why the lint timed out and failed unfortunately. |
Thanks for the PR! I'm unable to review it today, but I'll take a look soon. |
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.
The changes look good and there's only one thing that could be improved. This also needs a rebase.
The servicePort created for each Jaeger receiver does not currently set a Protocol, and therefore defaults to TCP. Some Jaeger receiver protocols (i.e. thrift_binary and thrift_compact) are UDP based rather than TCP, and therefore the operator currently creates service port entries that cannot be used due to the protocol mismatch.
Reduces code duplication by setting the port's protocol consistently, rather than conditionally based the supplied configuration.
Thanks for the review! I've resolved the issue you found and re-based with the latest changes. I've re-run the tests locally and re-confirmed that it also works as expected on my cluster. |
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. I'll wait for your OK to merge, as you might have a better name for the protocol
property in the protocol
struct.
Rename protocol to transportProtocol, where protocol refers to a transport protocol (i.e. TCP/UDP) to reduce ambiguity between transport protocols and application protocols.
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. Thank you for your patience and for your contribution!
Awesome! Thank you for your review and constructive feedback too! |
…etry#117) The service port created for each Jaeger receiver does not currently set a Protocol, and therefore defaults to TCP. Some Jaeger receiver protocols (i.e. thrift_binary and thrift_compact) are UDP based rather than TCP, and therefore the operator currently creates service port entries that cannot be used due to the protocol mismatch. For example, the following manifest will currently create service port entries with the wrong protocol for thrift_compact and thrift_binary protocols; ``` apiVersion: opentelemetry.io/v1alpha1 kind: OpenTelemetryCollector metadata: name: simplest spec: config: | receivers: jaeger: protocols: grpc: thrift_compact: thrift_binary: thrift_http: processors: queued_retry: exporters: logging: loglevel: debug service: pipelines: traces: receivers: [jaeger] processors: [queued_retry] exporters: [logging] ``` ``` Type: ClusterIP IP: 10.233.59.118 Port: jaeger-grpc 14250/TCP TargetPort: 14250/TCP Endpoints: 10.233.110.188:14250 Port: jaeger-thrift-http 14268/TCP TargetPort: 14268/TCP Endpoints: 10.233.110.188:14268 Port: jaeger-thrift-compact 6831/TCP TargetPort: 6831/TCP Endpoints: 10.233.110.188:6831 Port: jaeger-thrift-binary 6832/TCP TargetPort: 6832/TCP Endpoints: 10.233.110.188:6832 ``` This PR fixes this behavior by extending the protocol struct to also include each Jaeger receiver protocol's protocol and set the service port's protocol when a new Jaeger receiver is created. I have also updated the Jaeger receiver test cases to expect the correct service port protocol for each Jaeger receiver protocol, and they all pass. I have also tested this manually against my own cluster and confirmed that the service port protocol is set for UDP for thrift_binary and thrift_compact both when an endpoint is explicitly defined and when left unset. I'm still quite new to OpenTelemetry, so i'm open to feedback if i've misunderstood things!
…etry#117) The service port created for each Jaeger receiver does not currently set a Protocol, and therefore defaults to TCP. Some Jaeger receiver protocols (i.e. thrift_binary and thrift_compact) are UDP based rather than TCP, and therefore the operator currently creates service port entries that cannot be used due to the protocol mismatch. For example, the following manifest will currently create service port entries with the wrong protocol for thrift_compact and thrift_binary protocols; ``` apiVersion: opentelemetry.io/v1alpha1 kind: OpenTelemetryCollector metadata: name: simplest spec: config: | receivers: jaeger: protocols: grpc: thrift_compact: thrift_binary: thrift_http: processors: queued_retry: exporters: logging: loglevel: debug service: pipelines: traces: receivers: [jaeger] processors: [queued_retry] exporters: [logging] ``` ``` Type: ClusterIP IP: 10.233.59.118 Port: jaeger-grpc 14250/TCP TargetPort: 14250/TCP Endpoints: 10.233.110.188:14250 Port: jaeger-thrift-http 14268/TCP TargetPort: 14268/TCP Endpoints: 10.233.110.188:14268 Port: jaeger-thrift-compact 6831/TCP TargetPort: 6831/TCP Endpoints: 10.233.110.188:6831 Port: jaeger-thrift-binary 6832/TCP TargetPort: 6832/TCP Endpoints: 10.233.110.188:6832 ``` This PR fixes this behavior by extending the protocol struct to also include each Jaeger receiver protocol's protocol and set the service port's protocol when a new Jaeger receiver is created. I have also updated the Jaeger receiver test cases to expect the correct service port protocol for each Jaeger receiver protocol, and they all pass. I have also tested this manually against my own cluster and confirmed that the service port protocol is set for UDP for thrift_binary and thrift_compact both when an endpoint is explicitly defined and when left unset. I'm still quite new to OpenTelemetry, so i'm open to feedback if i've misunderstood things!
The service port created for each Jaeger receiver does not currently set a Protocol, and therefore defaults to TCP. Some Jaeger receiver protocols (i.e. thrift_binary and thrift_compact) are UDP based rather than TCP, and therefore the operator currently creates service port entries that cannot be used due to the protocol mismatch. For example, the following manifest will currently create service port entries with the wrong protocol for thrift_compact and thrift_binary protocols;
This PR fixes this behavior by extending the protocol struct to also include each Jaeger receiver protocol's protocol and set the service port's protocol when a new Jaeger receiver is created. I have also updated the Jaeger receiver test cases to expect the correct service port protocol for each Jaeger receiver protocol, and they all pass. I have also tested this manually against my own cluster and confirmed that the service port protocol is set for UDP for thrift_binary and thrift_compact both when an endpoint is explicitly defined and when left unset.
I'm still quite new to OpenTelemetry, so i'm open to feedback if i've misunderstood things!