+1 Thanks, Tao Jiuming
Yunze Xu <x...@apache.org>于2023年7月31日 周一16:26写道： > 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. >
