Hi, ## Motivation
Pulsar brokers serve two kinds of client-side requests: data panel requests (often known as client-api) and control panel requests (often known as admin-api). Pulsar has multiple client libraries support among Java, C++, Python, Golang, C#, Node.js, etc. While most of them implement the client-api, currently, only the Java library implements the admin-api. Nowadays, many Pulsar deployments are in cloud environments, where Golang dominates the domain. Thus, there is an increasing requirement to make control panel requests with integrations of those Golang libraries. StreamNative invented pulsar-admin-go[1] during its development of Pulsar Cloud services. The library is open-sourced months ago[2]. Now, we’d propose donating this library to the Apache Pulsar project cause Apache provides a solid way to release software, and we may find some opportunities to deduplicate code between pulsar-admin-go and pulsar-client-go. [1] https://github.com/streamnative/pulsar-admin-go [2] https://github.com/apache/pulsar/discussions/19932 ## Features pulsar-admin-go follows all the features that Java’s pulsar-client-admin provides. Currently, it supports management over: - BrokerStats - Brokers - Clusters - Functions - FunctionsWorker - Namespaces - NsIsolationPolicy - Packages - ResourceQuotas - Schema - Sinks - Sources - Subscriptions - Tenants - Topics ## Development The open issue for pulsar-admin-go’s development is how we organize code into repos for pulsar-admin-go and pulsar-client-go. Java’s pulsar-client-admin depends on pulsar-client. Although pulsar-admin-go doesn’t depend on pulsar-client-go, they share the same code implementation of auth logics. Generally, maintaining duplicate code is not a good idea. So we have two ways to avoid this situation. The first one is hosting code in three repos: pulsar-admin-go, pulsar-client-go, pulsar-auth-go. Then factor out the shared auth logics into pulsar-auth-go and let pulsar-admin-go and pulsar-client-go depend on it. In this way, although it provides a clear boundary between modules, it may increase the burden of managing issues and releasing them. Thus, I’d prefer the second approach: hosting pulsar-client-go and pulsar-admin-go code both under the current apache/pulsar-client-go repo, and deduplicate auth logics by letting pulsar-admin-go use the current auth logic provided in pulsar-client-go. In this way, we simplify the process of managing issues and doing releases, while we should take more care of how to release these three logically separated modules in one repo. If nowadays Golang can compile code in packages, we should be fine to merge pulsar-admin-go code just into apache/pulsar-client-go in packages. Otherwise, we should refactor the code into three go modules. For version strategy, as Java’s pulsar-client-admin and pulsar-client do simultaneous releases, pulsar-client-go and pulsar-admin-go can do simultaneous releases also. I expect that pulsar-admin-go doesn’t evolve quite rapidly to require its own release cycle, but almost bugfixes along with the evolution of pulsar-client-go. ## Schedule [ ] Consensus on the overall direction [ ] Consensus on the repo organizing strategy [ ] IP clearance [ ] Repo transfer and setup Looking forward to your feedback! Best, tison.
