Thanks for your reply! I'm going to call a vote now for a consensus on the donating direction.
Then I'll handle the IP clearance process. For repo organizing strategy, I recognize Zixuan's suggestion that fine-grained modules can help downstream projects to use and combine them more flexibly. While the technical works are always "merge auth code, unifying APIs, separate modules", I suggest we host the code all under the pulsar-client-go repo first and split them into auth, client, and admin if there are requirements and volunteers. Best, tison. Enrico Olivelli <eolive...@gmail.com> 于2023年8月1日周二 05:55写道： > +1 > > Thanks > Enrico > > Il giorno lun 31 lug 2023 alle ore 17:59 Zixuan Liu > <node...@gmail.com> ha scritto: > > > > This is a good idea for the Pulsar community. > > > > > 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. > > > > I prefer this idea. The `go get` depends on the git tag/branch/commit, > > when three modules are in one repo, this version number can cause > > confusion. > > > > Thanks, > > Zixuan > > > > 太上玄元道君 <dao...@apache.org> 于2023年7月31日周一 17:19写道： > > > > > > +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. > > > > >
