EronWright opened a new pull request #12079: URL: https://github.com/apache/pulsar/pull/12079
Master Issue: #12040 Related: #3501 ### Motivation This PR decouples the advertised listener configuration from the broker bind addresses, and fixes a few places where the broker is assumes to have a plaintext cluster endpoint or conflates the TLS/plaintext endpoints. The goal is to support a specific configuration, where the broker has an advertised listener corresponding to an Istio gateway, and the gateway terminates TLS (`pulsar+ssl://...`). Because Istio uses mTLS transparently within the mesh, the broker has only a plaintext server endpoint (`pulsar://...`). Without this patch, the broker rejects the configuration because it erroneously assumes that the broker should have a TLS binding to support a TLS advertised address. This PR deprecates the `PulsarService::getSafeBrokerServiceUrl` method, which returns a plaintext endpoint if available, and a TLS endpoint otherwise. The resultant endpoint is then advertised to Pulsar clients but the scheme information isn't always considered. Observe that client code disregards the scheme in some cases: https://github.com/apache/pulsar/blob/d81b5f8b8e6cb17f307ec830accaf9dd95d7643b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/HttpLookupService.java#L95-L105 Note that this PR is focused on the Pulsar protocol endpoints, not the REST API endpoints. ### Modifications - Remove validation logic that compares the advertised listener against the bind addresses. - Deprecate `PulsarService::getSafeBrokerServiceUrl` and be explicit about which address is used. - Update broker code to not assume there's a plaintext endpoint for the broker. - ### Verifying this change - [ ] Make sure that the change passes the CI checks. This change is already covered by existing tests, such as: - `MultipleListenerValidatorTest` ### Does this pull request potentially affect one of the following parts: - The public API: yes The information that is returned by the broker is slightly different in the case of a pure-TLS broker. In that case, lookup results (which consist of a pair of URLs) might not have a plaintext URL. In concept a client could break, though in practice this is unlikely since the broker didn't really work in such a configuration anyway. ### Documentation Need to update docs? - [ ] no-need-doc Internal changes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
