This repository was archived by the owner on Jan 24, 2024. It is now read-only.
[FEATURE] advertised listener protocol map #829
Assignees
Labels
type/feature
Indicates new functionality
Comments
|
Related: #818 |
BewareMyPower
added a commit
that referenced
this issue
Oct 28, 2021
It's a code cleanup for `EndPoint` related code. - Change `multiListener` to `validInProtocolMap` because this field indicates whether the `EndPoint`'s listener name is contained in a protocol map. - Add a new overloaded version of `parseListeners` that accepts a map, since we might add a new protocol map in future. See #829. - Add a `newKafkaChannelInitializer` method to create a `KafkaChannelInitializer` according to whether TLS is enabled for the endpoint. So in future, if we modified the constructor of `KafkaChannelInitializer`, only one place would need changes. - Use `KafkaServiceConfiguration` as the parameter of `KopBrokerLookupManager`'s constructor since we might store a protocol map that is parsed from config in this class.
BewareMyPower
added a commit
that referenced
this issue
Oct 29, 2021
It's a code cleanup for `EndPoint` related code. - Change `multiListener` to `validInProtocolMap` because this field indicates whether the `EndPoint`'s listener name is contained in a protocol map. - Add a new overloaded version of `parseListeners` that accepts a map, since we might add a new protocol map in future. See #829. - Add a `newKafkaChannelInitializer` method to create a `KafkaChannelInitializer` according to whether TLS is enabled for the endpoint. So in future, if we modified the constructor of `KafkaChannelInitializer`, only one place would need changes. - Use `KafkaServiceConfiguration` as the parameter of `KopBrokerLookupManager`'s constructor since we might store a protocol map that is parsed from config in this class.
BewareMyPower
added a commit
that referenced
this issue
Oct 29, 2021
It's a code cleanup for `EndPoint` related code. - Change `multiListener` to `validInProtocolMap` because this field indicates whether the `EndPoint`'s listener name is contained in a protocol map. - Add a new overloaded version of `parseListeners` that accepts a map, since we might add a new protocol map in future. See #829. - Add a `newKafkaChannelInitializer` method to create a `KafkaChannelInitializer` according to whether TLS is enabled for the endpoint. So in future, if we modified the constructor of `KafkaChannelInitializer`, only one place would need changes. - Use `KafkaServiceConfiguration` as the parameter of `KopBrokerLookupManager`'s constructor since we might store a protocol map that is parsed from config in this class.
|
Am closing this because no improvement is apparently needed for this scenario to work. That is because the metadata response doesn't include protocol information; the client uses properties to activate SSL: |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is your feature request related to a problem? Please describe.
Master issue: apache/pulsar#12040
For Istio integration, it is important to be able to advertise an SSL listener representing the Istio gateway. The gateway is expected to terminate TLS and to forward the traffic to a PLAINTEXT endpoint. Currently it is impossible to advertise an SSL listener that binds to a plaintext server socket. Recall that Istio uses mTLS to transparently encrypt traffic within the mesh, which means that the broker need not have a TLS configuration for its server sockets.
Describe the solution you'd like
Introduce an
kafkaAdvertisedProtocolMapconfiguration property that works likekafkaProtocolMapbut applies to thekafkaAdvertisedListeners. If the property is not defined, fall back tokafkaProtocolMap. Be sure to use the map in the topic lookup procedure to make the resultant address.Describe alternatives you've considered
None
The text was updated successfully, but these errors were encountered: