Re: [DISCUSS] PIP-143 : Standardize Admin REST API

[mattison chao]

+1

Best,
Mattison

> On Mar 22, 2022, at 9:55 AM, PengHui Li  wrote:
> 
> +1
> 
> Penghui
> 
> On Fri, Mar 18, 2022 at 11:00 AM guo jiwei  wrote:
> 
>> Ok, I have updated the proposal number to 149.
>> https://github.com/apache/pulsar/issues/14365.
>> 
>> Regards
>> Jiwei Guo (Tboy)
>> 
>> 
>> On Wed, Mar 16, 2022 at 8:53 PM PengHui Li  wrote:
>> 
>>> PIP-143 is this one https://github.com/apache/pulsar/issues/13761
>>> 
>>> Please peek a new proposal number
>>> 
>>> Penghui
>>> 
>>> On Wed, Mar 16, 2022 at 8:43 PM guo jiwei  wrote:
>>> 
 Hello community,
 
I want to discuss refactoring and standardizing REST API. Users
>> have
 encountered several deadlock problems in the API part before, like
>> #13666
 , #12590
 . After fixing the above
>>> two
 issues, we check the related part and find that there are still numbers
>>> of
 asynchronous call synchronous implementations for other functions of
>> the
 REST API. To avoid more problems, I would like to discuss the
 standardization of API modules and create the PIP-142  #14365
  . Feel free to comment
>> and
 give suggestions.
 
 
 
 
 Regards
 Jiwei Guo (Tboy)
 
>>> 
>> 

S3 objects deletion failures...how to recover?

[Enrico Olivelli]

Hello,
we (actually Dave) recently found that the S3 offloader did not delete
the objects.

This is a quick fix for the problem
https://github.com/apache/pulsar/pull/14694

I am working on a set of integration tests to prevent these kinds of
problems for the future.

But I would like to start a discussion about how to recover from the
side effects of this bug:
Users have old Blobs that must be deleted, for costs saving and also
because in some countries there are strict rules about guarantees of
deleting data when it is no longer needed (for instance European
GDPR).

I am working on a tool that scans in the background existing objects
on Tiered Storage and then performs cleaning up.

The basic version of this "sweeper" tool:
- searches for orphan objects
- logs them ("dry run" mode) or delete them

This tool may be launched manually, or it can run as a k8s job periodically.

Thoughts ?

Enrico

[GitHub] [pulsar-client-node] lipeining closed issue #181: A bug about MessageListenerProxy, got a nullptr of data->consumer(Consumer.cc#64)

[GitBox]

lipeining closed issue #181:
URL: https://github.com/apache/pulsar-client-node/issues/181


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] PIP-143 : Standardize Admin REST API

[Haiting Jiang]

+1

Thanks,
Haiting

On 2022/03/16 12:43:45 guo jiwei wrote:
> Hello community,
> 
> I want to discuss refactoring and standardizing REST API. Users have
> encountered several deadlock problems in the API part before, like #13666
> , #12590
> . After fixing the above two
> issues, we check the related part and find that there are still numbers of
> asynchronous call synchronous implementations for other functions of the
> REST API. To avoid more problems, I would like to discuss the
> standardization of API modules and create the PIP-142  #14365
>  . Feel free to comment and
> give suggestions.
> 
> 
> 
> 
> Regards
> Jiwei Guo (Tboy)
> 

Re: [DISCUSS] PIP-143 : Standardize Admin REST API

[石宝迪]

+1


> 在 2022年3月22日，19:59，Haiting Jiang  写道：
> 
> +1
> 
> Thanks,
> Haiting
> 
>> On 2022/03/16 12:43:45 guo jiwei wrote:
>> Hello community,
>> 
>>I want to discuss refactoring and standardizing REST API. Users have
>> encountered several deadlock problems in the API part before, like #13666
>> , #12590
>> . After fixing the above two
>> issues, we check the related part and find that there are still numbers of
>> asynchronous call synchronous implementations for other functions of the
>> REST API. To avoid more problems, I would like to discuss the
>> standardization of API modules and create the PIP-142  #14365
>>  . Feel free to comment and
>> give suggestions.
>> 
>> 
>> 
>> 
>> Regards
>> Jiwei Guo (Tboy)
>> 

Re: [Discuss] draft PIP for "Changes to GitHub Actions based Pulsar CI"

[Lari Hotari]

I have resumed work to improve our GitHub Actions based Pulsar CI.

Last year, I worked on a proof-of-concept which significantly reduced the 
resource consumption and improved the usability of the build by combining 
multiple workflows into a single larger workflow. 

The showstopper a year ago was the lack of being able to re-run a single failed 
job in a larger workflow. 
GitHub has since then delivered this feature and no showstoppers are present.

I have been posting updates to https://github.com/apache/pulsar/issues/14401 
"Speed up CI workflows" about the progress. 
I have rebased the changes from last year's PoC, and I'm finalizing and testing 
the changes in my fork under https://github.com/lhotari/pulsar/pull/59 . I'll 
send a PR to apache/pulsar, when the refactoring is ready.

-Lari

On 2021/03/16 01:10:52 Sijie Guo wrote:
> > The prototype has demonstrated about 60% reduction in
> resource consumption.
> 
> It is hard to quantify. Merging them into one large workflow can result in
> more failures. Re-running those failures can consume resources as well.
> 
> > Isn't it urgent to resolve it?
> 
> I think we are in a stage that gives us breathing room to fix flaky tests
> and solve other problems, no?
> I don't mean we stop the effort here. I mean we have other enhancements
> that we can do to improve the situation.
> Once we get into a position where the flakiness is reduced, we can merge
> them into one workflow.
> 
> - Sijie
> 
> 
> On Mon, Mar 15, 2021 at 2:48 AM Lari Hotari  wrote:
> 
> > Thanks for the feedback Sijie.
> >
> > > We are using a lazy consensus approach. Typically if there is no
> > objection,
> > > please go ahead and not need to wait for approval.
> > > If people raise concerns, please address the concerns.
> >
> > You and Ali have raised concerns about changing the existing GitHub Actions
> > workflows in a way where multiple workflows would be combined to a single
> > workflow. Before proceeding, there is a need to address the concerns. We
> > might end up with a completely different type of solution of what has been
> > proposed initially. :)
> >
> > > Yes. So I am in favor of addressing flaky tests than merging all
> > workflows
> > > into one giant workflow.
> >
> > I agree that addressing flaky tests is favorable. The main reason for PIP
> > "Changes to GitHub Actions based Pulsar CI" is to
> > 1) Reduce GitHub Action Runner resource consumption of Pulsar PR builds
> > 2) Reduce lead times for Pull Request feedback
> > We cannot ignore these problems. If we don't change anything, the problems
> > won't get fixed. The prototype has demonstrated about 60% reduction in
> > resource consumption. Measuring the lead times hasn't been done in the
> > prototype, but since the reason for long lead times has been long build
> > queues due to excessive resource consumption, it's likely that the lead
> > times would be reduced.
> >
> > I know that switching to a single workflow isn't the only solution to the
> > above problems. I had a discussion with Ali. He recommended reducing the
> > modules in Pulsar repository (PIP-62), reducing the docker container size
> > and improving the Pulsar Broker unit test harness so that tests using it
> > would be less flaky and that it would be easier to fix the issues in
> > failing test when there would be better information about what was the
> > state problem that caused the test to fail.
> >
> > As mentioned in the earlier email about the optimizations in the Pulsar CI
> > refactoring prototype, the main benefits come from reusing binary artifacts
> > from previous build stages so that each job doesn't have to build
> > everything from scratch. This becomes irrelevant when the build is very
> > fast and there isn't a benefit of reusing artifacts.
> > This means that it's possible to resolve the resource consumption problem
> > of Pulsar PR builds in the way that Ali is recommending, without switching
> > from multiple workflows to a single workflow that can reuse binary
> > artifacts in the build.
> >
> > > Hence I am +1 to "changes to flaky test handing" and suggest focusing
> > more
> > > on solving flaky tests.
> > > Consider merging them into one workflow when the tests are in a better
> > > situation.
> >
> > Makes sense for minimizing the risk of change, but we cannot just wait for
> > things to fix themselves.
> > How long will other Apache projects tolerate the resource consumption
> > issues Pulsar is causing in the shared GitHub Actions Runner VM quota? For
> > example, https://github.com/apache/pulsar/pull/9159#issuecomment-766915396
> > .
> > Isn't it urgent to resolve it?
> >
> > I'll revisit the plan for PIP  "Changes to GitHub Actions based Pulsar CI"
> > based on the community feedback in the upcoming days. That might mean that
> > the current solution is pivoted. The goal is to solve the problems of high
> > resource consumption and long lead time for PR build in Pulsar CI. Please
> > continue to provide feedback so that we

Re: [Discuss] draft PIP for "Changes to GitHub Actions based Pulsar CI"

[Enrico Olivelli]

Lari,

Il Mar 22 Mar 2022, 14:32 Lari Hotari  ha scritto:

> I have resumed work to improve our GitHub Actions based Pulsar CI.
>
> Last year, I worked on a proof-of-concept which significantly reduced the
> resource consumption and improved the usability of the build by combining
> multiple workflows into a single larger workflow.
>
> The showstopper a year ago was the lack of being able to re-run a single
> failed job in a larger workflow.
> GitHub has since then delivered this feature and no showstoppers are
> present.
>
> I have been posting updates to
> https://github.com/apache/pulsar/issues/14401 "Speed up CI workflows"
> about the progress.
> I have rebased the changes from last year's PoC, and I'm finalizing and
> testing the changes in my fork under
> https://github.com/lhotari/pulsar/pull/59 . I'll send a PR to
> apache/pulsar, when the refactoring is ready.
>

This is great news !

Looking forward to your patch

Enrico



> -Lari
>
> On 2021/03/16 01:10:52 Sijie Guo wrote:
> > > The prototype has demonstrated about 60% reduction in
> > resource consumption.
> >
> > It is hard to quantify. Merging them into one large workflow can result
> in
> > more failures. Re-running those failures can consume resources as well.
> >
> > > Isn't it urgent to resolve it?
> >
> > I think we are in a stage that gives us breathing room to fix flaky tests
> > and solve other problems, no?
> > I don't mean we stop the effort here. I mean we have other enhancements
> > that we can do to improve the situation.
> > Once we get into a position where the flakiness is reduced, we can merge
> > them into one workflow.
> >
> > - Sijie
> >
> >
> > On Mon, Mar 15, 2021 at 2:48 AM Lari Hotari  wrote:
> >
> > > Thanks for the feedback Sijie.
> > >
> > > > We are using a lazy consensus approach. Typically if there is no
> > > objection,
> > > > please go ahead and not need to wait for approval.
> > > > If people raise concerns, please address the concerns.
> > >
> > > You and Ali have raised concerns about changing the existing GitHub
> Actions
> > > workflows in a way where multiple workflows would be combined to a
> single
> > > workflow. Before proceeding, there is a need to address the concerns.
> We
> > > might end up with a completely different type of solution of what has
> been
> > > proposed initially. :)
> > >
> > > > Yes. So I am in favor of addressing flaky tests than merging all
> > > workflows
> > > > into one giant workflow.
> > >
> > > I agree that addressing flaky tests is favorable. The main reason for
> PIP
> > > "Changes to GitHub Actions based Pulsar CI" is to
> > > 1) Reduce GitHub Action Runner resource consumption of Pulsar PR builds
> > > 2) Reduce lead times for Pull Request feedback
> > > We cannot ignore these problems. If we don't change anything, the
> problems
> > > won't get fixed. The prototype has demonstrated about 60% reduction in
> > > resource consumption. Measuring the lead times hasn't been done in the
> > > prototype, but since the reason for long lead times has been long build
> > > queues due to excessive resource consumption, it's likely that the lead
> > > times would be reduced.
> > >
> > > I know that switching to a single workflow isn't the only solution to
> the
> > > above problems. I had a discussion with Ali. He recommended reducing
> the
> > > modules in Pulsar repository (PIP-62), reducing the docker container
> size
> > > and improving the Pulsar Broker unit test harness so that tests using
> it
> > > would be less flaky and that it would be easier to fix the issues in
> > > failing test when there would be better information about what was the
> > > state problem that caused the test to fail.
> > >
> > > As mentioned in the earlier email about the optimizations in the
> Pulsar CI
> > > refactoring prototype, the main benefits come from reusing binary
> artifacts
> > > from previous build stages so that each job doesn't have to build
> > > everything from scratch. This becomes irrelevant when the build is very
> > > fast and there isn't a benefit of reusing artifacts.
> > > This means that it's possible to resolve the resource consumption
> problem
> > > of Pulsar PR builds in the way that Ali is recommending, without
> switching
> > > from multiple workflows to a single workflow that can reuse binary
> > > artifacts in the build.
> > >
> > > > Hence I am +1 to "changes to flaky test handing" and suggest focusing
> > > more
> > > > on solving flaky tests.
> > > > Consider merging them into one workflow when the tests are in a
> better
> > > > situation.
> > >
> > > Makes sense for minimizing the risk of change, but we cannot just wait
> for
> > > things to fix themselves.
> > > How long will other Apache projects tolerate the resource consumption
> > > issues Pulsar is causing in the shared GitHub Actions Runner VM quota?
> For
> > > example,
> https://github.com/apache/pulsar/pull/9159#issuecomment-766915396
> > > .
> > > Isn't it urgent to resolve it?
> > >
> > > I'll rev

Re: [DISCUSS] Create a nightly docker image

[Ziyao Wei]

Cool, thanks for the ideas! I agree it makes sense to separate the
nightlies from the other versions.

Just curious what's the advantage of using Artifactory over using Docker
Hub? I read it has better access control but I don't have any experience
with it.

Also, I could send an email out to bui...@apache.org to ask for access, but
since I am not a committer/project member yet, would it be better if
someone else closer to Apache does it?


Best,

Ziyao


On Sat, Mar 19, 2022 at 7:13 AM Enrico Olivelli  wrote:

> Il Sab 19 Mar 2022, 06:02 Dave Fisher  ha scritto:
>
> > The ASF has a JFrog artifactory instance that could help.
>
>
> +1
>
> It must be clear that they are official releases and they MUST not be used
> in Production
>
> We could also publish snapshots of Maven jars to repository.apache.org
>
> Enrico
>
> Ask on bui...@apache.org!
> >
> > Regards,
> > Dave
> >
> > Sent from my iPhone
> >
> > > On Mar 18, 2022, at 9:53 PM, PengHui Li  wrote:
> > >
> > > I think we can use a separate org to maintain the nightly builded
> > snapshot
> > > images?
> > > So that the external repo can pull the latest image from the new org.
> > >
> > > Regards,
> > > Penghui
> > >
> > >
> > >
> > >
> > >> On Sat, Mar 19, 2022 at 12:33 PM Ziyao Wei
> > >>  wrote:
> > >>
> > >> Hi Pulsar developers,
> > >>
> > >>
> > >> Recently on Docker Hub the `latest` image has been changed from 2.8.2
> to
> > >> 2.9.1. As a result, the Golang client CI is failing. I have been
> > debugging
> > >> the issue, but to help timely detection of similar issues in the
> future
> > and
> > >> to ease debugging, I propose we should create a nightly Docker image
> for
> > >> Pulsar builds.
> > >>
> > >> I filed https://github.com/apache/pulsar/issues/14755, and the
> > arguments
> > >> are as follows:
> > >>
> > >> *Is your enhancement request related to a problem? Please describe.*
> > >>
> > >> Currently Docker Hub only contains release images for Pulsar. This
> makes
> > >> doing CI for dependent repos harder, since they wouldn't be able to
> test
> > >> again the bleeding edge easily, and has led to issues such as
> > >> https://github.com/apache/pulsar-client-go/issues/748 where it's
> > unclear
> > >> which Pulsar change caused the issue.
> > >>
> > >> (The linked issue was made worse because the latest image has been
> > outdated
> > >> by ~6 months, but 1) even if that's not the case we'd still only be
> > able to
> > >> catch issues between releases, and 2) the fact that the Golang client
> is
> > >> using latest points to a need of having a nightly.)
> > >>
> > >> *Describe the solution you'd **like*
> > >>
> > >> Create a nightly build so external repos can always point against it
> and
> > >> catch issues as early as possible.
> > >>
> > >> *Describe alternatives you've considered*
> > >>
> > >> The external repos can also try to pull in the latest Pulsar code, but
> > that
> > >> seems harder and needs more per repo configuration.
> > >>
> > >> @eolivelli suggested I post this here so it can be discussed. Opinions
> > and
> > >> ideas are welcome, thanks!
> > >>
> > >>
> > >> Best,
> > >>
> > >> Ziyao
> > >>
> >
> >
>

Re: [DISCUSS] Create a nightly docker image

[Enrico Olivelli]

Il giorno mar 22 mar 2022 alle ore 15:21 Ziyao Wei
 ha scritto:
>
> Cool, thanks for the ideas! I agree it makes sense to separate the
> nightlies from the other versions.
>
> Just curious what's the advantage of using Artifactory over using Docker
> Hub? I read it has better access control but I don't have any experience
> with it.

The problem is that people MUST NOT think that those images can be
used in production.
If something is in DockerHub then it is easier for people to think
that it can be used in production.

>
> Also, I could send an email out to bui...@apache.org to ask for access, but
> since I am not a committer/project member yet, would it be better if
> someone else closer to Apache does it?

I can help. You can DM me in Slack

>
>
> Best,
>
> Ziyao
>
>
> On Sat, Mar 19, 2022 at 7:13 AM Enrico Olivelli  wrote:
>
> > Il Sab 19 Mar 2022, 06:02 Dave Fisher  ha scritto:
> >
> > > The ASF has a JFrog artifactory instance that could help.
> >
> >
> > +1
> >
> > It must be clear that they are official releases and they MUST not be used
> > in Production
> >
> > We could also publish snapshots of Maven jars to repository.apache.org
> >
> > Enrico
> >
> > Ask on bui...@apache.org!
> > >
> > > Regards,
> > > Dave
> > >
> > > Sent from my iPhone
> > >
> > > > On Mar 18, 2022, at 9:53 PM, PengHui Li  wrote:
> > > >
> > > > I think we can use a separate org to maintain the nightly builded
> > > snapshot
> > > > images?
> > > > So that the external repo can pull the latest image from the new org.
> > > >
> > > > Regards,
> > > > Penghui
> > > >
> > > >
> > > >
> > > >
> > > >> On Sat, Mar 19, 2022 at 12:33 PM Ziyao Wei
> > > >>  wrote:
> > > >>
> > > >> Hi Pulsar developers,
> > > >>
> > > >>
> > > >> Recently on Docker Hub the `latest` image has been changed from 2.8.2
> > to
> > > >> 2.9.1. As a result, the Golang client CI is failing. I have been
> > > debugging
> > > >> the issue, but to help timely detection of similar issues in the
> > future
> > > and
> > > >> to ease debugging, I propose we should create a nightly Docker image
> > for
> > > >> Pulsar builds.
> > > >>
> > > >> I filed https://github.com/apache/pulsar/issues/14755, and the
> > > arguments
> > > >> are as follows:
> > > >>
> > > >> *Is your enhancement request related to a problem? Please describe.*
> > > >>
> > > >> Currently Docker Hub only contains release images for Pulsar. This
> > makes
> > > >> doing CI for dependent repos harder, since they wouldn't be able to
> > test
> > > >> again the bleeding edge easily, and has led to issues such as
> > > >> https://github.com/apache/pulsar-client-go/issues/748 where it's
> > > unclear
> > > >> which Pulsar change caused the issue.
> > > >>
> > > >> (The linked issue was made worse because the latest image has been
> > > outdated
> > > >> by ~6 months, but 1) even if that's not the case we'd still only be
> > > able to
> > > >> catch issues between releases, and 2) the fact that the Golang client
> > is
> > > >> using latest points to a need of having a nightly.)
> > > >>
> > > >> *Describe the solution you'd **like*
> > > >>
> > > >> Create a nightly build so external repos can always point against it
> > and
> > > >> catch issues as early as possible.
> > > >>
> > > >> *Describe alternatives you've considered*
> > > >>
> > > >> The external repos can also try to pull in the latest Pulsar code, but
> > > that
> > > >> seems harder and needs more per repo configuration.
> > > >>
> > > >> @eolivelli suggested I post this here so it can be discussed. Opinions
> > > and
> > > >> ideas are welcome, thanks!
> > > >>
> > > >>
> > > >> Best,
> > > >>
> > > >> Ziyao
> > > >>
> > >
> > >
> >

[GitHub] [pulsar-site] Paul-TT opened a new pull request #22: Adding latest blog post link to home page and docs alert style update

[GitBox]

Paul-TT opened a new pull request #22:
URL: https://github.com/apache/pulsar-site/pull/22


   This latest change includes a change to:
   
   - home page : adding latest blog post to the promo call out beneath hero 
section
   - docs: style updates to the alert notice colors


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Jacoco and Codecov.io integration for Code Coverage reports

[Enrico Olivelli]

Nicolò,
Great stuff indeed.
Some comments inline below

Thanks


Il Mer 16 Mar 2022, 16:45 Nicolò Boschi  ha scritto:

> Dear community,
>
> Currently we don't have an aggregate code coverage report. There's a Jacoco
> configuration to generate the report after unit tests but it is not
> easily readable and understandable.
>
> Having a better system would bring a couple of interesting aspects:
> 1. We can block a pull request if the code coverage decreases - that means
> there are no tests for the new code.
>

I am afraid that this would lead to some automatic excessive nitpicking.
Let's keep this in the 'future works' basket

2. We can have an overview for each modules and discover which features are
> less covered and add new tests
>
> I would like to introduce a new tool that reads, aggregates, stores and
> reports the code coverage for the whole codebase. This tool is Codecov (
> https://about.codecov.io/) that is one of the most popular tools for open
> source projects.
> It brings multiple advantages:
> 1. It aggregates all the Jacoco reports in a single report
> 2. It keeps the coverage history
> 3. It is well integrated with Github
>
> The idea is the following:
> - Add this profiling in the CI - for each test suite and upload the results
> to codecov.io
> - Enable the codecov report that add a comment in the pull
>
>
> Implementation pull: https://github.com/apache/pulsar/pull/14600
> Codecov comment in the PR:
> https://github.com/apache/pulsar/pull/14600#issuecomment-1061636495
> Codecov full report:
>
> https://codecov.io/gh/apache/pulsar/tree/0fa212d40b2bf166b20f3155c40fdb9624f577ed
>
> Initially there were some doubts around whether the jacoco agent would have
> added a significant overhead (execution time + memory usage). I've seen
> (and you can see the checks times in my pull) that it is not relevant in
> the Pulsar codebase.
>
> The pull only adds Jacoco coverage for unit tests. Integrating jacoco with
> the integration tests (inside docker) will be more complex but it is
> possible. We can do it in a second moment.
> You basically need to add the jacoco agent inside the docker container,
> enabling it in the java command and downloading the report files before the
> container stops.
>
>
> Note: Codecov is free for open source projects (
> https://about.codecov.io/pricing/). It is required to install the app on
> Github Marketplace (https://github.com/marketplace/codecov).
>

Is it something we should ask to ASF infra probably.

The PMC can deal with this

Enrico


> BR,
> Nicolò Boschi
>

Re: [Discuss] Generate cert and key files automatically

[Yunze Xu]

Good point. It's because generating a certificate automatically is not safe,
right? If so, I think there is no need to add this feature since the motivation
is to make the code more intuitive.

Thanks,
Yunze




> 2022年3月22日 上午12:40，Enrico Olivelli  写道：
> 
> Il giorno lun 21 mar 2022 alle ore 16:31 Yunze Xu
>  ha scritto:
>> 
>> Hi all,
>> 
>> Recently I found a document error when configuring Pulsar client for TLS
>> encryption. See https://github.com/apache/pulsar/issues/14762. However, the 
>> code
>> example in the official documents is more intuitive.
>> 
>> See https://pulsar.apache.org/docs/en/security-tls-transport/#java-client, 
>> the
>> example code doesn't configure `AuthenticationTls`, but it is required once 
>> TLS
>> encryption is enabled, even if TLS authentication is not enabled. Because the
>> client side can only send a SSL handshake via `AuthenticationTls`. It would 
>> be
>> confused.
>> 
>> Since the cert file and the key file are generated using a CA, whose path is
>> specified by `tlsTrustCertsFilePath` method, I think it would be possible to
>> generate a cert and a key file automatically. We only need to specify a 
>> common
>> name, which represents the role when authentication is enabled.
> 
> Usually a service cannot generate a "valid" certificate automatically,
> it MUST be signed by a CA.
> 
> We may add an option to automatically generate a certificate (and a
> CA) but that will work only for
> DEV environments.
> 
> Enrico
> 
> 
>> 
>> My initial design is, when client configures the `tlsTrustCertsFilePath`:
>> - If no authentication plugin is enabled, generate the cert and key files
>>  automatically using a default common name.
>> - Otherwise, use the cert and key files specified in `AuthenticationTls`.
>> 
>> The benefit is, when you want to pass the TLS authentication, you must 
>> configure
>> `AuthenticationTls` at client side, while you only needs to configure
>> `tlsTrustCertsFilePath` if broker side only enables TLS encryption.
>> 
>> What do you think? Is there a better solution?
>> 
>> Thanks,
>> Yunze
>> 
>> 
>> 
>> 

Re: [Discuss] Generate cert and key files automatically

[Yunze Xu]

If `tlsCertFilePath` and `tlsKeyFilePath` were added to the client builder
options, I think they can also be used for TLS authentication as well.

I prefer this solution now just because it looks like generating certificats
automatically is not good, from what Enrico said.

The problem is that what if we configured both `AuthenticationTls` and those
two options? Because the underlying mechanisms are the same that a `SslContext`
is created from the cert and key files and then the `SslContext` object will be
used in the TCP or HTTP transport.

I think the priority of `AuthenticationTls` must be higher. Then it should be
encouraged to use `AuthenticationTls` when TLS authentication is enabled at
broker side. Otherwise, these two options should be encouraged to use.

Thanks,
Yunze




> 2022年3月22日 上午11:03，Zixuan Liu  写道：
> 
> Hi Yunze,
> 
> The current implementation is confusing, we should split the transport and
> auth for TLS.
> 
> For transport, the code can be so like:
> ```
> PulsarClient client = PulsarClient.builder()
>.enableTls(true)
>.tlsTrustCertsFilePath("ca.pem")
>.tlsCertFilePath("client-ca.pem")
>.tlsKeyFilePath("client-key.pem")
>.build();
> ```
> 
> For auth, the code can be so like:
> ```
> Map authParams = new HashMap<>();
> authParams.put("tlsCertFile", "client-ca.pem");
> authParams.put("tlsKeyFile", "client-key.pem");
> PulsarClient client = PulsarClient.builder()
>.enableTls(true)
>.tlsTrustCertsFilePath("ca.pem")
>.authentication(AuthenticationTls.class.getName(),
> authParams)
>.build();
> ```
> 
> When using the TLS auth, we don't need to set
> tlsCertFilePath("client-ca.pem") and tlsKeyFilePath("client-key.pem"), the
> authentication instead of this.
> 
> There have an important thing that if we are using the authentication with
> the token, we cannot setup the TLS transport.
> 
> 
> Enrico Olivelli  于2022年3月22日周二 00:40写道：
> 
>> Il giorno lun 21 mar 2022 alle ore 16:31 Yunze Xu
>>  ha scritto:
>>> 
>>> Hi all,
>>> 
>>> Recently I found a document error when configuring Pulsar client for TLS
>>> encryption. See https://github.com/apache/pulsar/issues/14762. However,
>> the code
>>> example in the official documents is more intuitive.
>>> 
>>> See
>> https://pulsar.apache.org/docs/en/security-tls-transport/#java-client, the
>>> example code doesn't configure `AuthenticationTls`, but it is required
>> once TLS
>>> encryption is enabled, even if TLS authentication is not enabled.
>> Because the
>>> client side can only send a SSL handshake via `AuthenticationTls`. It
>> would be
>>> confused.
>>> 
>>> Since the cert file and the key file are generated using a CA, whose
>> path is
>>> specified by `tlsTrustCertsFilePath` method, I think it would be
>> possible to
>>> generate a cert and a key file automatically. We only need to specify a
>> common
>>> name, which represents the role when authentication is enabled.
>> 
>> Usually a service cannot generate a "valid" certificate automatically,
>> it MUST be signed by a CA.
>> 
>> We may add an option to automatically generate a certificate (and a
>> CA) but that will work only for
>> DEV environments.
>> 
>> Enrico
>> 
>> 
>>> 
>>> My initial design is, when client configures the `tlsTrustCertsFilePath`:
>>> - If no authentication plugin is enabled, generate the cert and key files
>>>  automatically using a default common name.
>>> - Otherwise, use the cert and key files specified in `AuthenticationTls`.
>>> 
>>> The benefit is, when you want to pass the TLS authentication, you must
>> configure
>>> `AuthenticationTls` at client side, while you only needs to configure
>>> `tlsTrustCertsFilePath` if broker side only enables TLS encryption.
>>> 
>>> What do you think? Is there a better solution?
>>> 
>>> Thanks,
>>> Yunze
>>> 
>>> 
>>> 
>>> 
>> 

Re: [VOTE] PIP-136: Sync Pulsar policies across multiple clouds

[Rajan Dhabalia]

>> Do we need to provide the ability for users to decide to replicate the
ACLs and replication cluster or not?

This feature allows users to sync two separate clusters which are having
independent global-zookeeper (metadata-store) instances. So, this feature
will not be limited to sync a few fields of policies but think in terms of
auto creation and syncing namespaces/tenants to entirely different
metadata-stores where they can not talk to each other.

>> BTW, we already supported topic level replication cluster
configuration[5], looks like in this case, [5]
https://github.com/apache/pulsar/pull/12136

Again, #12136 talks about applying policies to topics but this PIP
addresses a separate problem where it makes it possible to integrate
independent/isolated metadata-stores  with each other.

Thanks,
Rajan

On Mon, Mar 21, 2022 at 6:29 PM PengHui Li  wrote:

> Thanks for the explanation.
>
> > yes, local policies doesn't need to be replicate to other clusters and it
> will only replicate global policies which is shared across multiple
> clusters such tenant/namespace's identity-creation, ACLs, replication
> clusters, etc.
>
> As described in this blog [1], section "Aggregation Replication".
> Do we need to provide the ability for users to decide to replicate
> the ACLs and replication cluster or not?
>
> Currently, if users want to achieve "Aggregation Replication", it needs
> multiple configuration stores. So they need to maintain the namespace,
> partitioned topics in each cluster. A new namespace created in one cluster,
> it need to create the namespace in other clusters if they want to replicate
> data to those clusters.
>
> After this proposal, they don't need to create a namespace for other
> clusters,
> Pulsar will help to replicate the configuration store changes to the
> replicated cluster,
> if the new created namespace with replication cluster A, B, and C in
> cluster A, the
> namespace will be replicated to B and C.
>
> But for the ACLs and replication clusters, it should be controlled by
> users?
> e.g. only replicate the namespace to B and C, but not the replication
> clusters and ACLs.
> So that we can achieve "Aggregation Replication" with this proposal.
>
> > Topic that will be used to share policies across clusters is configurable
> and it can be named anything. However, we should keep it a separate topic
> as it requires unique schema and special handling to synchronize policies
> across the clusters.
>
> Yes, looks like currently we already have a mechanism to replicate
> policies.
> We have a system topic under the namespace "__change_events", which only
> has
> topic policy changes for now. It can replicate anything under a namespace.
> We have defined "EventType"[2] in PulsarEvent(structure used in
> "__change_events").
> And we already have a implementation for selective PulsarEvent
> replication[3], and schema
> replication[4].
>
> So it looks like we can use the "__change_events" to replicate namespace
> policies, and use a
> new topic which belongs to a system namespace to replicate
> tenant/namespace's identity-creation,
> partitioned topic creation?
>
> BTW, we already supported topic level replication cluster configuration[5],
> looks like in this case,
> the partitioned topic is created first in one cluster without replication
> clusters first, after the replication
> clusters changed, pulsar will replicate the partitioned topic to remote
> cluster. The same mechanism is
> required for non-partitioned topics(users might disabled the topic
> auto-creation).
>
> [1]
>
> https://www.splunk.com/en_us/blog/devops/geo-replication-in-apache-pulsar-part-2-patterns-and-practices.html
> [2]
>
> https://github.com/apache/pulsar/blob/4dcb166e0bfcce7fc85fd8d59a25b881f6f9c6fa/pulsar-common/src/main/java/org/apache/pulsar/common/events/PulsarEvent.java#L36
> [3]
>
> https://github.com/apache/pulsar/wiki/PIP-92%3A-Topic-policy-across-multiple-clusters
> [4]
>
> https://github.com/apache/pulsar/wiki/PIP-88%3A-Replicate-schemas-across-multiple
> [5] https://github.com/apache/pulsar/pull/12136
>
> Regards,
> Penghui
>
> On Tue, Mar 22, 2022 at 6:37 AM Rajan Dhabalia 
> wrote:
>
> > >> If it contains namespace policy replication, There are some policies
> no
> > need to replicate to another cluster
> > yes, local policies doesn't need to be replicate to other clusters and it
> > will only replicate global policies which is shared across multiple
> > clusters such tenant/namespace's identity-creation, ACLs, replication
> > clusters, etc.
> >
> > >> The new partitioned topic also needs to be replicated to the remote
> > cluster?
> > Yes.
> >
> > Topic that will be used to share policies across clusters is configurable
> > and it can be named anything. However, we should keep it a separate topic
> > as it requires unique schema and special handling to synchronize policies
> > across the clusters.
> >
> > Thanks,
> > Rajan
> >
> > On Fri, Mar 18, 2022 at 9:12 PM PengHui Li  wrote:
> >
> > > Hi Rajan,

Re: [VOTE] PIP-136: Sync Pulsar policies across multiple clouds

[PengHui Li]

> This feature allows users to sync two separate clusters which are having
independent global-zookeeper (metadata-store) instances. So, this feature
will not be limited to sync a few fields of policies but think in terms of
auto creation and syncing namespaces/tenants to entirely different
metadata-stores where they can not talk to each other.

Yes, we are on the same page. If this proposal is for syncing
tenant/namespace/topic
between multiple metadata stores, it looks good to me. If the proposal also
wants to
sync the namespace policy between multiple metadata stores, I think we
should leverage
the existing __change_events topic under each namespace.

> Again, #12136 talks about applying policies to topics but this PIP
addresses a separate problem where it makes it possible to integrate
independent/isolated metadata-stores  with each other.

Yes, it's not the same problem, but related. The namespace can disabled the
geo-replication but enabled in topic level, in this case if we have
multiple metadata store,
and if the topic is a partitioned topic, we also need a way to sync the
partitioned metadata
to the remote cluster's metadata store?

Thanks,
Penghui

On Wed, Mar 23, 2022 at 3:39 AM Rajan Dhabalia  wrote:

> >> Do we need to provide the ability for users to decide to replicate the
> ACLs and replication cluster or not?
>
> This feature allows users to sync two separate clusters which are having
> independent global-zookeeper (metadata-store) instances. So, this feature
> will not be limited to sync a few fields of policies but think in terms of
> auto creation and syncing namespaces/tenants to entirely different
> metadata-stores where they can not talk to each other.
>
> >> BTW, we already supported topic level replication cluster
> configuration[5], looks like in this case, [5]
> https://github.com/apache/pulsar/pull/12136
>
> Again, #12136 talks about applying policies to topics but this PIP
> addresses a separate problem where it makes it possible to integrate
> independent/isolated metadata-stores  with each other.
>
> Thanks,
> Rajan
>
> On Mon, Mar 21, 2022 at 6:29 PM PengHui Li  wrote:
>
> > Thanks for the explanation.
> >
> > > yes, local policies doesn't need to be replicate to other clusters and
> it
> > will only replicate global policies which is shared across multiple
> > clusters such tenant/namespace's identity-creation, ACLs, replication
> > clusters, etc.
> >
> > As described in this blog [1], section "Aggregation Replication".
> > Do we need to provide the ability for users to decide to replicate
> > the ACLs and replication cluster or not?
> >
> > Currently, if users want to achieve "Aggregation Replication", it needs
> > multiple configuration stores. So they need to maintain the namespace,
> > partitioned topics in each cluster. A new namespace created in one
> cluster,
> > it need to create the namespace in other clusters if they want to
> replicate
> > data to those clusters.
> >
> > After this proposal, they don't need to create a namespace for other
> > clusters,
> > Pulsar will help to replicate the configuration store changes to the
> > replicated cluster,
> > if the new created namespace with replication cluster A, B, and C in
> > cluster A, the
> > namespace will be replicated to B and C.
> >
> > But for the ACLs and replication clusters, it should be controlled by
> > users?
> > e.g. only replicate the namespace to B and C, but not the replication
> > clusters and ACLs.
> > So that we can achieve "Aggregation Replication" with this proposal.
> >
> > > Topic that will be used to share policies across clusters is
> configurable
> > and it can be named anything. However, we should keep it a separate topic
> > as it requires unique schema and special handling to synchronize policies
> > across the clusters.
> >
> > Yes, looks like currently we already have a mechanism to replicate
> > policies.
> > We have a system topic under the namespace "__change_events", which only
> > has
> > topic policy changes for now. It can replicate anything under a
> namespace.
> > We have defined "EventType"[2] in PulsarEvent(structure used in
> > "__change_events").
> > And we already have a implementation for selective PulsarEvent
> > replication[3], and schema
> > replication[4].
> >
> > So it looks like we can use the "__change_events" to replicate namespace
> > policies, and use a
> > new topic which belongs to a system namespace to replicate
> > tenant/namespace's identity-creation,
> > partitioned topic creation?
> >
> > BTW, we already supported topic level replication cluster
> configuration[5],
> > looks like in this case,
> > the partitioned topic is created first in one cluster without replication
> > clusters first, after the replication
> > clusters changed, pulsar will replicate the partitioned topic to remote
> > cluster. The same mechanism is
> > required for non-partitioned topics(users might disabled the topic
> > auto-creation).
> >
> > [1]
> >
> >
> https://www.splunk.com/

Re: [VOTE] Pulsar Release 2.10.0 Candidate 4

[Haiting Jiang]

+1

- Compiled the source
- Checked checksums and signatures
- Validate Pub/Sub and Java Functions
- Validate Connectors
- Validate Stateful Functions

Thanks
Haiting

On 2022/03/22 01:52:36 PengHui Li wrote:
> This is the fourth release candidate for Apache Pulsar 2.10.0
> 
> It fixes the following issues:
> https://github.com/apache/pulsar/pulls?q=is%3Apr+milestone%3A2.10.0+is%3Amerged+-label%3Arelease%2F2.9.1+-label%3Arelease%2F2.9.2
> 
> *** 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.10.0-candidate-4/
> 
> SHA-512 checksums:
> 
> f4ff0c5e06b7c09a6508f106be4287b47f4dfa6c2e1ec88d6a38ee767731428fde183ed2ce778aff89aece8fb1b06d5f1ada982817545be9a11c6e146913f7ab
> apache-pulsar-2.10.0-bin.tar.gz
> 
> 1f6c98c6dede135a73858d29be055a76a178b31b861dd8ef4ef33cb7951f95fc13a5c5ad5bee35abb0ad6420b4d7a763175c46cb1f90786fe865fd075e4d85c6
> apache-pulsar-2.10.0-src.tar.gz
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1154/
> 
> The tag to be voted upon:
> v2.10.0-candidate-3 (6d3fbbea4e9aaaf183ff4117d368b19d9ab6ad7e)
> https://github.com/apache/pulsar/releases/tag/v2.10.0-candidate-4
> 
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> 
> Docker images:
> 
> https://hub.docker.com/layers/198540978/lph890127/pulsar/2.10.0-rc4/images/sha256-e4e3a6593ff3d7ca4b5ffca718fdb423370d2566fb34efadf5a69423331a04ff?context=repo
> 
> https://hub.docker.com/layers/198537125/lph890127/pulsar-all/2.10.0-rc4/images/sha256-53b6d69920b5b2115e147f6ed54a4bcef65fb0855dbced8a7ad5d45b2dd5c776?context=repo
> 
> Please download the source package, and follow the Release Candidate
> Validation[1]
> to validate the release
> 
> [1] https://github.com/apache/pulsar/wiki/Release-Candidate-Validation
> 
> Thanks,
> Penghui
> 

[GitHub] [pulsar-client-node] massakam opened a new pull request #205: Upgrade minimist to 1.2.6

[GitBox]

massakam opened a new pull request #205:
URL: https://github.com/apache/pulsar-client-node/pull/205


   `minimist` module has a security vulnerability, so I ran `npm audit fix` to 
upgrade it. 
   ```sh
   $ npm audit
   
   # npm audit report
   
   minimist  <=1.2.5
   Severity: high
   Prototype Pollution in minimist - 
https://github.com/advisories/GHSA-xvch-5gv4-984h
   fix available via `npm audit fix`
   node_modules/minimist
   
   1 high severity vulnerability
   
   To address all issues, run:
 npm audit fix
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [Discuss] Generate cert and key files automatically

[Zixuan Liu]

> I think the priority of `AuthenticationTls` must be higher. Then it
should be encouraged to use `AuthenticationTls` when TLS authentication is
enabled at broker side. Otherwise, these two options should be encouraged
to use.

You are right, if we are set up the `AuthenticationTls` and TLS transport,
we should use the `AuthenticationTls` data to set up, `AuthenticationTls`
must be higher. When the user set up two config, we need to throw an
expectation that only use the `AuthenticationTls`, or `tlsCertFilePath` and
`tlsKeyFilePath`.


Yunze Xu  于2022年3月23日周三 01:57写道：

> If `tlsCertFilePath` and `tlsKeyFilePath` were added to the client builder
> options, I think they can also be used for TLS authentication as well.
>
> I prefer this solution now just because it looks like generating
> certificats
> automatically is not good, from what Enrico said.
>
> The problem is that what if we configured both `AuthenticationTls` and
> those
> two options? Because the underlying mechanisms are the same that a
> `SslContext`
> is created from the cert and key files and then the `SslContext` object
> will be
> used in the TCP or HTTP transport.
>
> I think the priority of `AuthenticationTls` must be higher. Then it should
> be
> encouraged to use `AuthenticationTls` when TLS authentication is enabled at
> broker side. Otherwise, these two options should be encouraged to use.
>
> Thanks,
> Yunze
>
>
>
>
> > 2022年3月22日 上午11:03，Zixuan Liu  写道：
> >
> > Hi Yunze,
> >
> > The current implementation is confusing, we should split the transport
> and
> > auth for TLS.
> >
> > For transport, the code can be so like:
> > ```
> > PulsarClient client = PulsarClient.builder()
> >.enableTls(true)
> >.tlsTrustCertsFilePath("ca.pem")
> >.tlsCertFilePath("client-ca.pem")
> >.tlsKeyFilePath("client-key.pem")
> >.build();
> > ```
> >
> > For auth, the code can be so like:
> > ```
> > Map authParams = new HashMap<>();
> > authParams.put("tlsCertFile", "client-ca.pem");
> > authParams.put("tlsKeyFile", "client-key.pem");
> > PulsarClient client = PulsarClient.builder()
> >.enableTls(true)
> >.tlsTrustCertsFilePath("ca.pem")
> >.authentication(AuthenticationTls.class.getName(),
> > authParams)
> >.build();
> > ```
> >
> > When using the TLS auth, we don't need to set
> > tlsCertFilePath("client-ca.pem") and tlsKeyFilePath("client-key.pem"),
> the
> > authentication instead of this.
> >
> > There have an important thing that if we are using the authentication
> with
> > the token, we cannot setup the TLS transport.
> >
> >
> > Enrico Olivelli  于2022年3月22日周二 00:40写道：
> >
> >> Il giorno lun 21 mar 2022 alle ore 16:31 Yunze Xu
> >>  ha scritto:
> >>>
> >>> Hi all,
> >>>
> >>> Recently I found a document error when configuring Pulsar client for
> TLS
> >>> encryption. See https://github.com/apache/pulsar/issues/14762.
> However,
> >> the code
> >>> example in the official documents is more intuitive.
> >>>
> >>> See
> >> https://pulsar.apache.org/docs/en/security-tls-transport/#java-client,
> the
> >>> example code doesn't configure `AuthenticationTls`, but it is required
> >> once TLS
> >>> encryption is enabled, even if TLS authentication is not enabled.
> >> Because the
> >>> client side can only send a SSL handshake via `AuthenticationTls`. It
> >> would be
> >>> confused.
> >>>
> >>> Since the cert file and the key file are generated using a CA, whose
> >> path is
> >>> specified by `tlsTrustCertsFilePath` method, I think it would be
> >> possible to
> >>> generate a cert and a key file automatically. We only need to specify a
> >> common
> >>> name, which represents the role when authentication is enabled.
> >>
> >> Usually a service cannot generate a "valid" certificate automatically,
> >> it MUST be signed by a CA.
> >>
> >> We may add an option to automatically generate a certificate (and a
> >> CA) but that will work only for
> >> DEV environments.
> >>
> >> Enrico
> >>
> >>
> >>>
> >>> My initial design is, when client configures the
> `tlsTrustCertsFilePath`:
> >>> - If no authentication plugin is enabled, generate the cert and key
> files
> >>>  automatically using a default common name.
> >>> - Otherwise, use the cert and key files specified in
> `AuthenticationTls`.
> >>>
> >>> The benefit is, when you want to pass the TLS authentication, you must
> >> configure
> >>> `AuthenticationTls` at client side, while you only needs to configure
> >>> `tlsTrustCertsFilePath` if broker side only enables TLS encryption.
> >>>
> >>> What do you think? Is there a better solution?
> >>>
> >>> Thanks,
> >>> Yunze
> >>>
> >>>
> >>>
> >>>
> >>
>
>

[GitHub] [pulsar-site] urfreespace commented on a change in pull request #22: Adding latest blog post link to home page and docs alert style update

[GitBox]

urfreespace commented on a change in pull request #22:
URL: https://github.com/apache/pulsar-site/pull/22#discussion_r832817626



##
File path: site2/website-next/src/pages/index.js
##
@@ -149,7 +148,10 @@ export default function Home() {
   pulsingWaves.classList.add("show-waves");
 }, 50);
   });
-
+  // gets blog posts
+  const recentPosts = 
require("../../.docusaurus/docusaurus-plugin-content-blog/default/blog-post-list-prop-default.json");
+  const latestPost = recentPosts.items[0];
+  console.log(latestPost);

Review comment:
   please remove the test code @Paul-TT 




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-site] urfreespace commented on a change in pull request #22: Adding latest blog post link to home page and docs alert style update

[GitBox]

urfreespace commented on a change in pull request #22:
URL: https://github.com/apache/pulsar-site/pull/22#discussion_r832819026



##
File path: site2/website-next/src/pages/index.js
##
@@ -149,7 +148,10 @@ export default function Home() {
   pulsingWaves.classList.add("show-waves");
 }, 50);
   });
-
+  // gets blog posts
+  const recentPosts = 
require("../../.docusaurus/docusaurus-plugin-content-blog/default/blog-post-list-prop-default.json");

Review comment:
   Have you tried to run `npm run build`? I'm not sure if this will make 
the building fail, please take a test, thanks




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [VOTE] Pulsar Release 2.9.2 Candidate 4

[Lin Lin]

- Checked the signature
- Checked the SHA-512 checksums
- Start standalone
- Create tenant and namespace
- Publish messages and consume messages
- Check Function

Thanks,
 Lin Lin

Re: [VOTE] Pulsar Release 2.9.2 Candidate 4

[Hang Chen]

+1 (binding)

- Checked checksum and license
- Setup standalone  cluster and run pulsar perf to produce and consume
- Check the prometheus metrics
- Run open messaging to check produce and consume throughput and latency
- Check source and sink connector

Thanks,
Hang

Lin Lin  于2022年3月23日周三 12:12写道：
>
> - Checked the signature
> - Checked the SHA-512 checksums
> - Start standalone
> - Create tenant and namespace
> - Publish messages and consume messages
> - Check Function
>
> Thanks,
>  Lin Lin

[GitHub] [pulsar-client-node] nkurihar merged pull request #205: Upgrade minimist to 1.2.6

[GitBox]

nkurihar merged pull request #205:
URL: https://github.com/apache/pulsar-client-node/pull/205


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org