+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. > > >
