[VOTE] Pulsar Release 2.9.5 Candidate 3

[Cong Zhao]

This is the third release candidate for Apache Pulsar, version 2.9.5.

This release contains 105 commits by 32 contributors.
https://github.com/apache/pulsar/compare/v2.9.4...v2.9.5-candidate-3

*** Please download, test, and vote on this release. This vote will stay
open
for at least 72 hours ***

Note that we are voting upon the source (tag), binaries are provided for
convenience.

Source and binary files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.9.5-candidate-3/

SHA-512 checksums:
c5f1b06f2f7249616a07b732daa036546591c1aa9e9f37e88ddce6d3eaf3d78b2c6da548ef42946d20d70f9397cd5b55ea4e01fe5cb4aa96fb4608bd62635f67
apache-pulsar-2.9.5-bin.tar.gz

72dee0fb642a269c5d0aedfa3e56aee503f56af319b67e4628f39da8cdd44f0bbdcd019e121eafca32b7b7665959770a3d91f0618d157837808da9511e9011a40f
apache-pulsar-2.9.5-src.tar.gz

738478bbcf323080487f5645b4c1edb9f45d126a8a2cd7e8c5678c8569ec7b21042ecb6fdd4796b65c6a24bd1e5ad082f5c0d15eb1a64408be4f4c53a06d3ef660
apache-pulsar-offloaders-2.9.5-bin.tar.gz

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachepulsar-1223/

The tag to be voted upon:
v2.9.5-candidate-3 (7337470f33586aa639854266efe95c2fa32f48db)
https://github.com/apache/pulsar/releases/tag/v2.9.5-candidate-3

Pulsar's KEYS file containing PGP keys you use to sign the release:
https://downloads.apache.org/pulsar/KEYS

Docker images:


https://hub.docker.com/layers/czcoder/pulsar/2.9.5/images/sha256-9bcbad78a65a09b3fe5d3acd158574ad0eda4531cc8c49db16760a2ed1364070?context=explore


https://hub.docker.com/layers/czcoder/pulsar-all/2.9.5/images/sha256-94e50aa1d5b91be9698c959c787eaff0677bb3c65dd1a578b1a641fa5a1d1715?context=explore


https://hub.docker.com/layers/czcoder/pulsar-grafana/2.9.5/images/sha256-d857951e85b41fe7172769380ffbcac126c75dc476fdcb4755623600b3eb03e0?context=explore

Please download the source package, and follow the README to build
and run the Pulsar standalone service.

Thanks
Cong Zhao

Re: [Discuss] Add a phase to process pending PRs before code freeze

[Xiangying Meng]

Hi Yunze,

Thank you for bringing up this critical issue regarding pending PRs before
the code freeze. I appreciate your thoughtful insights and suggestions.

I'd like to share my thoughts on this. In previous releases, we didn't have
a formal code freeze announcement; instead, we had a discussion email. The
release manager would notify everyone when the cherry-picking process was
complete and ask if there were any other PRs that needed to be included.
After waiting for some time, the release manager would then create an RC
label, and any PRs cherry-picked after this label would not be included in
the release.

In light of your suggestions, I believe we can carefully review the PRs
cherry-picked after the discussion email and before sending a code freeze
email. This can help us avoid potential issues caused by someone
overlooking the discussion email and cherry-picking PRs that should not be
included or introducing other unstable factors. By adopting these changes,
we can address the concerns you've raised and improve the overall release
process.

Thank you again for raising this concern, and I'm confident that
implementing these improvements will be beneficial for our community.

Best regards,
Xiangying

On Mon, Apr 10, 2023 at 11:11 AM Yunze Xu 
wrote:

> To be more specific, we can send a discussion thread one week before
> the code freeze. Then,
> 1. The PRs opened after the time point won't be considered to be
> included in this release
> 2. If someone has some pending PRs that are aimed to be included in
> this release, it's better to comment in the discussion thread.
>
> For example, [1] aimed to drop the streaming dispatcher in 3.0.0.
> However, there was no PR yet. If the PR was opened today and merged
> very quickly, there might not be enough time to complete the review
> process. We cannot assume a PR won't receive any request change.
>
> [1] https://lists.apache.org/thread/ky2bkzlz93njx3ntnvkpd0l77qzzgcmv
>
> Thanks,
> Yunze
>
> On Mon, Apr 10, 2023 at 10:56 AM Yunze Xu  wrote:
> >
> > Hi community,
> >
> > I see the code freeze of Pulsar 3.0.0 is coming tomorrow. But I found
> > the release process still lacks a key step that pending PRs should be
> > taken carefully of instead of simply delaying them to the next
> > release.
> >
> > The following cases were very often seen:
> > 1. A PR has opened for some days and no one reviewed it.
> > 2. A reviewer left some comments and the author disappeared for some
> time.
> > 3. The author of a PR has addressed the requested changes but the
> > reviewer has disappeared for some time.
> >
> > As we know, Apache committers are volunteers and have their own jobs.
> > So the cases above are all acceptable. However, before a release, I
> > think the release managers must take the responsibility to handle the
> > cases above.
> >
> > IMO, we must address the cases about (at least 1 and 3 are
> > controllable) one week in advance. If the PR cannot be merged due to
> > the disappearance of the author, it's okay to delay it to the next
> > release. But the release managers should address the PRs actively.
> > They can help review the PRs. Or at least,
> > - for case 1: they can ping some committers that are familiar with the
> > scope of the PR to review it.
> > - for case 2: they can ping the author
> > - for case 3: they can ping the reviewer
> >
> > I see Zike noticed the time point of the code freeze last week:
> > https://lists.apache.org/thread/tczgh4y8lcy2y85652vkctbkcrs40nq4. But
> > there is no clear process for how to process the pending PRs before
> > the code freeze.
> >
> > Thanks,
> > Yunze
>

Re: [Discuss] Add a phase to process pending PRs before code freeze

[Zike Yang]

Hi, Yunze,

Thanks for raising this discussion. It's good to have the phase to
proceed with the PR reviewing and merging before the code freeze.

> But the release managers should address the PRs actively.
> They can help review the PRs. Or at least,

I think we should separate these two roles: Release Managers and Code
Reviewers. The case 1 and 3 are also not controllable for the release
manager. But I'm +1 for the release manager should help advance this
phase.

> we can send a discussion thread one week before the code freeze. Then,
> 1. The PRs opened after the time point won't be considered to be
> included in this release
> 2. If someone has some pending PRs that are aimed to be included in
> this release, it's better to comment in the discussion thread.

+1. Looks like it's more like a PR-freeze time point. I think the
timeline `one week before the code freeze` could be further discussed.

Thanks,
Zike Yang





Zike Yang

On Mon, Apr 10, 2023 at 11:11 AM Yunze Xu  wrote:
>
> To be more specific, we can send a discussion thread one week before
> the code freeze. Then,
> 1. The PRs opened after the time point won't be considered to be
> included in this release
> 2. If someone has some pending PRs that are aimed to be included in
> this release, it's better to comment in the discussion thread.
>
> For example, [1] aimed to drop the streaming dispatcher in 3.0.0.
> However, there was no PR yet. If the PR was opened today and merged
> very quickly, there might not be enough time to complete the review
> process. We cannot assume a PR won't receive any request change.
>
> [1] https://lists.apache.org/thread/ky2bkzlz93njx3ntnvkpd0l77qzzgcmv
>
> Thanks,
> Yunze
>
> On Mon, Apr 10, 2023 at 10:56 AM Yunze Xu  wrote:
> >
> > Hi community,
> >
> > I see the code freeze of Pulsar 3.0.0 is coming tomorrow. But I found
> > the release process still lacks a key step that pending PRs should be
> > taken carefully of instead of simply delaying them to the next
> > release.
> >
> > The following cases were very often seen:
> > 1. A PR has opened for some days and no one reviewed it.
> > 2. A reviewer left some comments and the author disappeared for some time.
> > 3. The author of a PR has addressed the requested changes but the
> > reviewer has disappeared for some time.
> >
> > As we know, Apache committers are volunteers and have their own jobs.
> > So the cases above are all acceptable. However, before a release, I
> > think the release managers must take the responsibility to handle the
> > cases above.
> >
> > IMO, we must address the cases about (at least 1 and 3 are
> > controllable) one week in advance. If the PR cannot be merged due to
> > the disappearance of the author, it's okay to delay it to the next
> > release. But the release managers should address the PRs actively.
> > They can help review the PRs. Or at least,
> > - for case 1: they can ping some committers that are familiar with the
> > scope of the PR to review it.
> > - for case 2: they can ping the author
> > - for case 3: they can ping the reviewer
> >
> > I see Zike noticed the time point of the code freeze last week:
> > https://lists.apache.org/thread/tczgh4y8lcy2y85652vkctbkcrs40nq4. But
> > there is no clear process for how to process the pending PRs before
> > the code freeze.
> >
> > Thanks,
> > Yunze

Re: [DISCUSS] PIP-255: Assign topic partitions to bundle by round robin

[PengHui Li]

Hi Lin,

> The load managed by each Bundle is not even. Even if the number of
partitions managed
   by each bundle is the same, there is no guarantee that the sum of the
loads of these partitions
   will be the same.

Do we expect that the bundles should have the same loads? The bundle is the
base unit of the
load balancer, we can set the high watermark of the bundle, e.g., the
maximum topics and throughput.
But the bundle can have different real loads, and if one bundle runs out of
the high watermark, the bundle
will be split. Users can tune the high watermark to distribute the loads
evenly across brokers.

For example, there are 4 bundles with loads 1, 3, 2, 4, the maximum load of
a bundle is 5 and 2 brokers.
We can assign bundle 0 and bundle 3 to broker-0 and bundle 1 and bundle 2
to broker-2.

Of course, this is the ideal situation. If bundle 0 has been assigned to
broker-0 and bundle 1 has been
assigned to broker-1. Now, bundle 2 will go to broker 1, and bundle 3 will
go to broker 1. The loads for each
broker are 3 and 7. Dynamic programming can help to find an optimized
solution with more bundle unloads.

So, should we design the bundle to have even loads? It is difficult to
achieve in reality. And the proposal
said, "Let each bundle carry the same load as possible". Is it the correct
direction for the load balancer?

> Doesn't shed loads very well. The existing default policy
ThresholdShedder has a relatively high usage
   threshold, and various traffic thresholds need to be set. Many clusters
with high TPS and small message
   bodies may have high CPU but low traffic; And for many small-scale
clusters, the threshold needs to be
   modified according to the actual business.

Can it be resolved by introducing the entry write/read rate to the bundle
stats?

> The removed Bundle cannot be well distributed to other Brokers. The load
information of each Broker
   will be reported at regular intervals, so the judgment of the Leader
Broker when allocating Bundles cannot
   be guaranteed to be completely correct. Secondly, if there are a large
number of Bundles to be redistributed,
   the Leader may make the low-load Broker a new high-load node when the
load information is not up-to-date.

Can we try to force-sync the load data of the brokers before performing the
distribution of a large number of
bundles?

For the Goal section in the proposal. It looks like it doesn't map to the
issues mentioned in the Motivation section.
IMO, the proposal should clearly describe the Goal, like which problem will
be resolved with this proposal.
Both of the above 3 issues or part of them. And what is the high-level
solution to resolve the issue,
and what are the pros and cons compared with the existing solution without
diving into the implementation section.

Another consideration is the default max bundles of a namespace is 128. I
don't think the common cases that need
to set 128 partitions for a topic. If the partitions < the bundle's count,
will the new solution basically be equivalent to
the current way?

If this is not a general solution for common scenarios. I support making
the topic-bundle assigner pluggable without
introducing the implementation to the Pulsar repo. Users can implement
their own assigner based on the business
requirement. Pulsar's general solution may not be good for all scenarios,
but it is better for scalability (bundle split)
and enough for most common scenarios. We can keep improving the general
solution for the general requirement
for the most common scenarios.

Regards,
Penghui


On Wed, Mar 22, 2023 at 9:52 AM Lin Lin  wrote:

>
> > This appears to be the "round-robin topic-to-bundle mapping" option in
> > the `fundBundle` function. Is this the only place that needs an update?
> Can
> > you list what change is required?
>
> In this PIP, we only discuss topic-to-bundle mapping
> Change is required:
> 1)
> When lookup, partitions is assigned to bundle:
> Lookup -> NamespaceService#getBrokerServiceUrlAsync ->
> NamespaceService#getBundleAsync ->
> NamespaceBundles#findBundle
> Consistent hashing is now used to assign partitions to bundle in
> NamespaceBundles#findBundle.
> We should add a configuration item partitionAssignerClassName, so that
> different partition assignment algorithms can be dynamically configured.
> The existing algorithm will be used as the default
> （partitionAssignerClassName=ConsistentHashingPartitionAssigner）
> 2)
> Implement a new partition assignment class RoundRobinPartitionAssigner.
> New partition assignments will be implemented in this class
>
>
> > How do we enable this "round-robin topic-to-bundle mapping option" (by
> > namespace policy and broker.conf)?
>
> In broker.conf, a new option called `partitionAssignerClassName`
>
> > Can we apply this option to existing namespaces? (what's the admin
> > operation to enable this option)?
>
> The cluster must ensure that all nodes use the same algorithm.
> Broker-level configuration can be made effective by restarting or

Re: [Discuss] Add a phase to process pending PRs before code freeze

[Christophe Bornet]

Hi Yunze,

Thanks for bringing this discussion.
I agree that there must be some step to remind everybody that a code
freeze is coming and that people should pay attention to their open
PRs if they want them included.
In a sense Zike's mail one week ago did this and was pretty clear on
what was going to happen. Nobody reacted to it with concern on their
open PR, so I guess there's no important one that can't wait for 3.1.
So I think we should go on with the code freeze as planned.
If anyone has a PR that they really want to see included and have real
motivation to not wait 3.1, please express it as soon as possible
here.
The StreamingDispatcher removal (or deprecation?) could well be one of
those PRs but it should be decided very quickly.
Also I want to remind that this release will already be a huge one
with features that have been merged into main in August and I think we
shouldn't add potential delays without care.

Thanks,
Christophe

Le lun. 10 avr. 2023 à 04:56, Yunze Xu  a écrit :
>
> Hi community,
>
> I see the code freeze of Pulsar 3.0.0 is coming tomorrow. But I found
> the release process still lacks a key step that pending PRs should be
> taken carefully of instead of simply delaying them to the next
> release.
>
> The following cases were very often seen:
> 1. A PR has opened for some days and no one reviewed it.
> 2. A reviewer left some comments and the author disappeared for some time.
> 3. The author of a PR has addressed the requested changes but the
> reviewer has disappeared for some time.
>
> As we know, Apache committers are volunteers and have their own jobs.
> So the cases above are all acceptable. However, before a release, I
> think the release managers must take the responsibility to handle the
> cases above.
>
> IMO, we must address the cases about (at least 1 and 3 are
> controllable) one week in advance. If the PR cannot be merged due to
> the disappearance of the author, it's okay to delay it to the next
> release. But the release managers should address the PRs actively.
> They can help review the PRs. Or at least,
> - for case 1: they can ping some committers that are familiar with the
> scope of the PR to review it.
> - for case 2: they can ping the author
> - for case 3: they can ping the reviewer
>
> I see Zike noticed the time point of the code freeze last week:
> https://lists.apache.org/thread/tczgh4y8lcy2y85652vkctbkcrs40nq4. But
> there is no clear process for how to process the pending PRs before
> the code freeze.
>
> Thanks,
> Yunze

Re: [DISCUSS] Dropping the StreamingDispatcher

[Christophe Bornet]

Shouldn't it first be deprecated before removal ?

Le mar. 4 avr. 2023 à 08:47, Enrico Olivelli  a écrit :
>
> Hello,
> It has been a long time that we have in the Pulsar code a new
> experimental Dispatcher implementation named StreamingDispatcher.
>
> https://github.com/apache/pulsar/pull/9056
>
> There are many flaky tests about that feature and I believe that it
> has never been used in Production by anyone, because it happened a few
> times that we did some changes in the regular Dispatcher and
> introduced bugs on the StreamingDispacther (usually manifested as
> flaky tests)
>
>
> I propose to drop the StreamingDispatcher code for Pulsar 3.0.
> I don't think we need a PIP for this, it is an experimental code that
> was never delivered as a production ready feature.
>
> If anyone is aware of users please chime in.
>
> If anyone wants to sponsor that feature and objects in removing this
> dead code (that we still have to maintain) please help us in
> completing the feature.
>
> On paper it is a very appealing feature, and I am disappointed in dropping it.
> On the other hand, this is dead code that we have to maintain with zero 
> benefit
>
> Thoughts ?
>
> Enrico

Call for projects and mentors for OSPP 2023

[Dianjin Wang]

Hi all,

Glad to share that Apache Pulsar is listed at the OSPP 2023 again. This
year, the Pulsar community can open 7 projects at most.

For OSPP 2023, the project idea will be open from 4/04, 2023 to 04/28,
2023(UTC+8). If you have great ideas, please reply to this email by
following the project template. Then I can help you to submit them.

OSPP asks that Pulsar committers, PMC members, and contributors be the
mentors; a mentor can only mentor one project. Both mentors and students
will receive financial awards for completed projects.

You may want to know about OSPP 2022, so refer to this email[1] for details.

--
[Template]

## Project Info
Project Name:
Project Description: (at most 1000 words)
Difficulty Level:
- [ ] Basic
- [ ] Advanced

Project Output Requirements:
Item 1:__
Item 2:__
Item 3:__
…

Project Technical Requirements:
Item 1:__
Item 2:__
Item 3:__
…

## Mentor Info
Mentor Name:
Mentor Email:
--

[1] https://lists.apache.org/thread/7pplcd4c35qjzt2o58qxykkty8qqxvt3

Best,
Dianjin Wang

Re: [DISCUSS] PIP-250: Add proxyVersion to CommandConnect

[Michael Marshall]

Thanks for your feedback Mattison and Xiangying. I'll note that the
PIP vote did close already and I have the implementation just about
done, but I'm happy to discuss this feature a bit more here.

> we should avoid coupling the concepts in the proxy and the broker

Sharing version information does not tightly couple the proxy and the
broker. It makes it easier to collect the relevant debugging
information that can help solve problems faster. The client already
tells the broker its version. Are you able to provide more insight
here?

> The proxy should be a separate component. Instead of continuing to couple the 
> relevant proxy concepts into the broker, everyone should be a client to the 
> broker.

I don't think this analogy holds true. The pulsar proxy is not a layer
4 proxy. It sends its own pulsar protocol messages. I want to quickly
know the proxy version when debugging issues observed in the broker,
and this is the only way I see for the broker to get this information.

> I think the intention behind this is excellent, but directly modifying the 
> protocol might be a bit too heavy-handed.

Do you disagree with sharing this information with the broker? I think
we generally view the protocol as lightweight.

> Wouldn't it be better to directly expose the proxyVersion and clientVersion 
> information via Prometheus metrics

Which server is producing these metrics? My goal is for the broker to
get this information so it can be part of the logs. The only way to
transport these metrics is via the protocol.

If there is a serious objection, I can add an option for the proxy to
withhold this data from the broker. However, I think we should enable
it by default.

Thanks,
Michael

On Sat, Apr 8, 2023 at 2:19 AM Xiangying Meng  wrote:
>
> Dear Michael,
>
> I think the intention behind this is excellent, but directly modifying the 
> protocol might be a bit too heavy-handed.
>  This approach may lead to data redundancy.
>  In large-scale clusters, every client connection would need to transmit the 
> extra proxy version information,
> which might increase network overhead.
> Therefore, we should consider a more lightweight solution.
>
> If the primary purpose of the proxy version information is for diagnostics or 
> auditing,
> we could explore alternative methods for collecting this information without 
> modifying the protocol level.
> Wouldn't it be better to directly expose the proxyVersion and clientVersion 
> information via Prometheus metrics,
> as mentioned in the "Future work(Anything else)`" section of the proposal?
>
> Please let me know what you think about this suggestion.
>
> Best regards,
> Xiangying
>
> On Thu, Apr 6, 2023 at 3:46 PM  wrote:
>>
>> Sorry for the late response.
>>
>> Why do we need to make the broker aware of the proxy when, by normal 
>> software design, we should avoid coupling the concepts in the proxy and the 
>> broker? The previous authentication was for historical reasons, but we 
>> should not continue to introduce this coupling.
>>
>> The proxy should be a separate component. Instead of continuing to couple 
>> the relevant proxy concepts into the broker, everyone should be a client to 
>> the broker.
>>
>> Best,
>> Mattison
>> On Feb 25, 2023, 01:12 +0800, Michael Marshall , wrote:
>> > Great suggestions, Enrico.
>> >
>> > > It would be interesting to reject connections on the Proxy if the
>> > > client tries to set that field.
>> >
>> > I support making the proxy reject invalid input. We could also have
>> > the client reject connections where the client connect command
>> > includes `original_principal`, `original_auth_data`, or
>> > `original_auth_method`, since those are also only meant to be sent by
>> > the proxy.
>> >
>> > > On the broker there is no way to distinguish a proxy from a client, 
>> > > that's fair.
>> >
>> > We can reject these connections when authentication and authorization
>> > are enabled. My draft PR includes such logic.
>> >
>> > Thanks,
>> > Michael
>> >
>> > On Fri, Feb 24, 2023 at 7:29 AM Enrico Olivelli  
>> > wrote:
>> > >
>> > > Makes sense.
>> > >
>> > > It would be interesting to reject connections on the Proxy if the
>> > > client tries to set that field.
>> > > On the broker there is no way to distinguish a proxy from a client, 
>> > > that's fair.
>> > > But on the proxy it is not expected to see a connection from another 
>> > > proxy.
>> > >
>> > > +1
>> > >
>> > > Enrico
>> > >
>> > > Il giorno ven 24 feb 2023 alle ore 10:00 Zike Yang  ha 
>> > > scritto:
>> > > > >
>> > > > > Hi, Michael
>> > > > >
>> > > > > Thanks for initiating this PIP.
>> > > > >
>> > > > > +1
>> > > > >
>> > > > > BR,
>> > > > > Zike Yang
>> > > > >
>> > > > >
>> > > > > Zike Yang
>> > > > >
>> > > > > On Fri, Feb 24, 2023 at 12:16 PM Michael Marshall 
>> > > > >  wrote:
>> > > > > > >
>> > > > > > > Hi Pulsar Community,
>> > > > > > >
>> > > > > > > In talking with Zike Yang on
>> > > > > > > https://github.com/apache/pulsar/pull/19540, we identified th

Re: [VOTE] Pulsar Node.js Client Release 1.8.2 Candidate 1

[Yunze Xu]

+1 (binding)

* Checked signatures and checksums
* Build from source and run e2e examples (Ubuntu 20.04 and Node.js v16.19.0)
* Install from NPM and run e2e examples with OAuth2 authentication
through StreamNative cloud (Ubuntu 20.04 and Node.js v16.19.0,
node:19-bullseye container)

Thanks,
Yunze

On Sun, Apr 9, 2023 at 9:04 PM Baodi Shi  wrote:
>
> Hi everyone,
>
> This is the first release candidate for Apache Pulsar Node.js client,
> version 1.8.2.
>
> It fixes the following issues:
> https://github.com/apache/pulsar-client-node/pulls?q=is%3Apr+label%3Arelease%2Fv1.8.2+is%3Aclosed
> 
>
> Please download the source files and review this release candidate:
> - Download the source package, verify shasum and asc
> - Follow the README.md  to build and run the Pulsar
> Node.js client.
>
> The release candidate package has been published to the npm registry:
>
> https://www.npmjs.com/package/pulsar-client/v/1.8.2-rc.1
>
> You can install it by `npm i pulsar-client@1.8.2-rc.1
> --pulsar_binary_host_mirror=
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/` and
> verify the package.
>
> You can refer to this repository to verify tls related features:
>
>- https://github.com/shibd/pulsar-client-tls-test
>
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.8.2-rc.1/
> 
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/pulsar/KEYS
>
> SHA-512 checksum:
>
> 2181fb2ebe22c806b8aaf4d3700c61bd2c6a8d240462bf5f870c16a882d1ca9fc3f164e3c139900145934e68f14f21cbaaeb232157f76f6c92e627dced3e861e
>  ./apache-pulsar-client-node-1.8.2.tar.gz
>
> The tag to be voted upon:
> v1.8.2-rc.1(769d7cc)
> https://github.com/apache/pulsar-client-node/releases/tag/v1.8.2-rc.1
>
> Please review and vote on the release candidate #1 for the version 1.8.2,
> as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
>
> Thanks,
> Baodi Shi