LGTM. Thanks, Yunze
On Wed, Jul 26, 2023 at 5:11 PM tison <wander4...@gmail.com> wrote: > > 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.
