To clarify, I mean to say that pulsar-client-go (pulsar) is the *only* module in the repository, with sub-packages that include pulsar, pulsar/auth and pulsaradmin
On Mon, Aug 14, 2023 at 3:52 PM Andy Walker <a...@andy.dev> wrote: > Before considering whether to split the code into multiple modules, one > must first ask if it makes sense to intermix three separate version numbers > and use each project independently from the others. I would argue that it > does not. > > Typically, with client libraries like this, they are either fully agnostic > (in which case the latest stable release is always best), or they are > pinned by major or minor semver component to the package they are a client > for, implementing whichever API interface is current for the matching > version. > > As far as I know, Pulsar does not officially support pluggable *versions* > of the administrative API, broker APIs, or authentication backend. Many > components are pluggable insofar as an implementation class can be > provided, but this is not part of the release cycle, and upgrading targets > such as the authentication providers outside of the Pulsar version is not > done---they are connected to the release version. There is no setting for > authorizationProviderVersion or adminAPIVersion. > > Given that pulsar-client-go represents the primary client interface to > pulsar, and given that both pulsar-client-go and pulsar-admin-go interact > with the same Pulsar version in any given deployment, I would vote that > they all live underneath of `pulsar-client-go` and are versioned together. > > On Mon, Jul 31, 2023 at 11:59 AM Zixuan Liu <node...@gmail.com> wrote: > >> 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. >> > > >> >
