Thanks for linking to the PIP-95 implementation PR #12056 [1]. I wasn't aware that it has been implemented.
That PR is what I thought that was missing. It is the implementation to achieve what PIP-61 described as "only return the corresponding service URL" and the PIP-95 design of "use a unique bind address for each listener". It is possible that there are gaps, but I think that we should cover the possible gaps. > Maybe that's not entirely true. You can configure 100s of listeners for all > schemes/protocols, but the code only returns the internal or requested or > first address for all 4 schemes (pulsar, pulsar+ssl, http, https, and one > service url, which i am not sure why it is needed, maybe for backward > compatibility). So while, it's not exactly approach 2, it's also not purely I think that this is expected and what PIP-61 and PIP-95 describe. The main problem of PIP-61 and PIP-95 is that there isn't documentation of how to properly configure the solution. The important piece of "bindAddresses" implemented in PIP-95 was missing from PIP-61 in the first place and it's likely that PIP-95 isn't fully completed. The PR 12056 description is perhaps the best documentation of the feature and provides an example of how to use the configuration: ************ bindAddresses=external:pulsar://0.0.0.0:6652,external:pulsar+ssl://0.0.0.0:6653 bindAddress=0.0.0.0 brokerServicePort=6650 brokerServicePortTls=6651 advertisedListeners=cluster:pulsar://broker-1.local:6650,cluster:pulsar+ssl://broker-1.local:6651,external:pulsar://broker-1.example.dev:6652,external:pulsar+ssl://broker-1.example.dev:6653 internalListenerName=cluster ************ As it can be seen, the "external" listener is bound to different ports than the default "cluster" listener (listener for the brokerServicePort and brokerServicePortlTls is specified with internalListenerName). The clear gaps in the PIP-61 and PIP-95 solution are in the admin API. There are multiple APIs where a redirect is sent back to the client. The PR 12072 [2] covers the topic lookup over the admin API, but doesn't cover all other cases where the redirect happens. This is already pointed out in a comment [3] on that PR. I think that PIP-338 should focus on covering the gaps and providing a design that is aligned with the current PIP-61 & PIP-95 implementation. -Lari 1 - https://github.com/apache/pulsar/pull/12056 2 - https://github.com/apache/pulsar/pull/12072 3 - https://github.com/apache/pulsar/pull/12072#issuecomment-921663472 On 2024/02/12 18:30:01 Girish Sharma wrote: > Reply inline, and also replied to the GH comment. > > On Mon, Feb 12, 2024 at 9:37 PM Lari Hotari <lhot...@apache.org> wrote: > > > The confusing detail is that in PIP-61 [1], the alternative that has been > > implemented in the Pulsar code base has been marked as the rejected > > alternative ("Return all advertised listeners(rejected)"). The preferred > > and proposed alternative "Only return the corresponding service URL" was > > never implemented. > > > > > Maybe that's not entirely true. You can configure 100s of listeners for all > schemes/protocols, but the code only returns the internal or requested or > first address for all 4 schemes (pulsar, pulsar+ssl, http, https, and one > service url, which i am not sure why it is needed, maybe for backward > compatibility). So while, it's not exactly approach 2, it's also not purely > approach 1. I can speculate and assume that in approach 1, the author meant > "one of each protocol" and that's actually what's implemented, but its not > clearly mentioned in the PIP. It would be great if we can get some input > from folks involved in PIP-61 and PIP-95 . Also, the wiki says PIP-95 [0] > is something else, while the PRs using PIP-95 [1] in commits refer to > something else [2] ! > > > [0] - > https://github.com/apache/pulsar/wiki/PIP-95:-Transaction-coordinator-loading-mechanism > [1] - https://github.com/apache/pulsar/pull/12056 > [2] - https://github.com/apache/pulsar/issues/12040 > > Regards >
