Re: [DISCUSS] Remove restful producer component

[Jiaqi Shen]

+1

By the way, why the restful consumer still not be completed?

Thanks,
Jiaqi Shen


Haiting Jiang  于2022年12月7日周三 15:56写道：

> > I think we can remove it first because it is not a complete feature.
> Anyone interested in working on it can find the code from the git history
> and migrate it to another repo.
>
> Looks like it's not a complete implementation of PIP-64, but the REST
> producer part seems to be working.
> And some users may be using this partial feature, so we need to
> consider the compatibility issue.
>
> It makes sense to move this out of the main repo. But I don't see a
> strong reason to remove it directly.
> We should try to provide transparent upgrading, but letting users
> "find the code from the git history and migrate it to another repo"
> doesn't seem like a good option here. This bar is too high for most
> users.
>
> Thanks,
> Haiting
>
> On Wed, Dec 7, 2022 at 1:42 PM  wrote:
> >
> > Hi Haiting
> > > Is it better to finish it first, and then remove this from the main
> repo?
> > I think we can remove it first because it is not a complete feature.
> Anyone interested in working on it can find the code from the git history
> and migrate it to another repo.
> >
> > Ps: it looks like the current implementation has some limits, maybe
> another contributor like to use a different way.
> >
> > Please let me know if you have any concerns or if I am missing
> something. Thanks a lot!
> >
> > Best
> > Mattison
> > On Dec 7, 2022, 12:10 +0800, Haiting Jiang ,
> wrote:
> > > Hi Mattison
> > >
> > > What's the status of "moving this feature to another project"
> > > Is it better to finish it first, and then remove this from the main
> repo?
> > >
> > > Thanks,
> > > Haiting
> > >
> > > On Tue, Dec 6, 2022 at 6:37 PM  wrote:
> > > >
> > > >
> > > > Hello, everyone.
> > > >
> > > > I'd like to start the discussion about `Remove restful producer
> component`. The Github repository path is here[1].
> > > >
> > > > As discussed before[2], moving this feature to another project is
> better. Also, we didn't provide the consumer part in the pulsar repo. I
> think it's a good chance to remove it after 2.11 is released.
> > > >
> > > > Best,
> > > > Mattison
> > > >
> > > > [1]
> https://github.com/apache/pulsar/tree/master/pulsar-broker/src/main/java/org/apache/pulsar/broker/rest
> > > > [2] https://lists.apache.org/thread/fl2rbb6sxlzwgkt7ybx4jxfkfnlb27z1
> > > >
> > > >
>

Re: [DISCUSS] Proposal required for Admin API/CLI and metrics changes

[PengHui Li]

> I agree a proposal would be better before adding a PR. But the
document part must be a part of such a proposal.

Make sense. It looks like we should have a checklist for the proposal.
The documentation changes should be listed in the proposal.

> Can the PR template/GitHub process check that if either the api changes
and doc-required are checked both are checked with textual information
provided?

It's a good idea.
I haven't tried, but it looks like it's possible.
We have this list:

```
### Does this pull request potentially affect one of the following parts:

*If the box was checked, please highlight the changes*

- [ ] Dependencies (add or upgrade a dependency)
- [ ] The public API
- [ ] The schema
- [ ] The default values of configurations
- [ ] The binary protocol
- [ ] The REST endpoints
- [ ] The admin CLI options
- [ ] Anything that affects deployment
```

And the CI can try to add labels `doc required` or `wants/proposal`
according to the
list selections.

And we can add `The metrics` item to the list.

Thanks,
Penghui

On Wed, Dec 7, 2022 at 1:52 PM Dave Fisher  wrote:

>
>
> Sent from my iPhone
>
> > On Dec 6, 2022, at 9:45 PM, Yunze Xu 
> wrote:
> >
> > Hi Penghui,
> >
> >> But maybe some are missed.
> >
> > That's the point. Each PR that adds or modifies a metric item must be
> > labeled with "doc-required" and the related documents should be added.
> > However, these PRs are nearly all labeled with "doc-not-needed".
> >
> > I agree a proposal would be better before adding a PR. But the
> > document part must be a part of such a proposal.
>
> Can the PR template/GitHub process check that if either the api changes
> and doc-required are checked both are checked with textual information
> provided?
>
> Best,
> Dave
> >
> > Thanks,
> > Yunze
> >
> >> On Wed, Dec 7, 2022 at 11:48 AM PengHui Li  wrote:
> >>
> >> Hi Yunze,
> >>
> >> All the metrics are listed here
> >> https://pulsar.apache.org/docs/2.10.x/reference-metrics/
> >>
> >> But maybe some are missed.
> >>
> >> Thanks,
> >> Penghui
> >>
> >> On Wed, Dec 7, 2022 at 11:46 AM Yunze Xu 
> >> wrote:
> >>
> >>> I agree. It should have required the PIP.
> >>>
> >>> I have another question. Is there any document to describe these
> >>> metrics? I think the metrics body should be documented well to avoid
> >>> breaking changes. Some external applications might parse the metrics
> >>> according to a specific structure.
> >>>
> >>> Thanks,
> >>> Yunze
> >>>
> >>> On Wed, Dec 7, 2022 at 11:38 AM PengHui Li  wrote:
> 
>  Hi all,
> 
>  I would like to start a discussion about requiring a proposal for
> Admin
>  API/CLI
>  and metrics changes.
> 
>  Here are some recent examples that changed the Admin API but without
>  proposals.
>  I just checked the commit logs. Maybe some have a proposal. Just
> forgot
> >>> to
>  add
>  the proposal link to the PR.
> 
>  https://github.com/apache/pulsar/pull/18218
>  https://github.com/apache/pulsar/pull/17153
>  https://github.com/apache/pulsar/pull/16167
>  https://github.com/apache/pulsar/pull/14930
>  https://github.com/apache/pulsar/pull/17337
> 
>  And here are metrics-related proposals. But looks like we don't have a
>  clear rule
>  for this part (the proposal is required or not)
> 
>  https://github.com/apache/pulsar/issues/18319
>  https://github.com/apache/pulsar/issues/18560
> 
>  As more and more users are using Pulsar in production.
>  But the Admin API changes and metrics changes have
>  not required a proposal. This may pose a risk to users.
>  The proposal will have better visibility, and voting is required.
> 
>  And actually, all the public API changes are proposals required.
> 
> >>>
> https://github.com/apache/pulsar/blob/master/wiki/proposals/PIP.md#when-is-a-pip-required
>  But in fact, this is not strictly enforced.
> 
>  Is it time to require a proposal for Admin API/CLI and metrics
> changes?
> 
>  Thanks,
>  Penghui
> >>>
>
>

Re: [DISCUSS] How to handle broker public API changes

[Haiting Jiang]

Hi all,

We already have working procedures to change the public API, like PIP
, mail-discussion and the PR templates.
>From what I understand, the problem is more like how to provide a
clear and proper definition of "Broker Public API".
I believe it's the reason why PIP-136 updated the method signature and
no one finds it until now.

And if we put the scope of "public API" to all the public methods in
the broker modules, it would be definitely too broad and slow our
development of other features.

Thanks,
Haiting

On Wed, Dec 7, 2022 at 1:50 PM  wrote:
>
> > I'm afraid it's very hard to avoid these API changes. Take theprotocol 
> > handler as example, it could make use of nearly all modulesvia the 
> > `PulsarService` object. The cost to keep the compatibilitymight be high so 
> > that much legacy code could be left. For example,each time a new argument 
> > is added to a method, we have to add anoverload to keep the compatibility. 
> > It could be confusing to peoplewho don't know these extensions and they 
> > might wonder why an overloadis needed that is never used in the Pulsar's 
> > main repo.
> Yes, I totally agree with your point. it's a trade-off,  I think we can hold 
> this discussion until the ecosystem becomes bigger and this problem becomes 
> more prominent.
>
> Best,
> Mattison
>
> On Dec 7, 2022, 13:37 +0800, Yunze Xu , wrote:
> > I'm afraid it's very hard to avoid these API changes. Take the
> > protocol handler as example, it could make use of nearly all modules
> > via the `PulsarService` object. The cost to keep the compatibility
> > might be high so that much legacy code could be left. For example,
> > each time a new argument is added to a method, we have to add an
> > overload to keep the compatibility. It could be confusing to people
> > who don't know these extensions and they might wonder why an overload
> > is needed that is never used in the Pulsar's main repo.
> >
> > The root cause is that we don't have an API abstraction for the
> > pulsar-broker module, like the pulsar-client-api module to the
> > pulsar-client mode. But it could be a huge project to add something
> > like pulsar-broker-api.
> >
> > Thanks,
> > Yunze
> >
> > On Wed, Dec 7, 2022 at 1:21 PM  wrote:
> > >
> > > > > It would help me understand if you would explain how apis were 
> > > > > changed in this PR
> > > Sorry, I explained above. it's a small break, maybe it just breaks some 
> > > unit test mock, but it can be used as an example.
> > > > > We should be sure to track and then highlight API changes in release 
> > > > > documents.
> > > > > API changes should be held until the next major version (now 2.12) 
> > > > > and be documented with that release.
> > > > > I think we need to be explicit in our GitHub PR template. I don’t 
> > > > > have a suggested edit yet, but the idea is to add text about
> > > > > 1. How the PR changes the API2. Which PIP authorizes it
> > > +1 for an awesome idea.
> > >
> > > Am I just wondering if we can avoid breaking it? maybe we can give the 
> > > old method a @Deprecated?
> > >
> > > Best,
> > > Mattison
> > > On Dec 7, 2022, 12:56 +0800, Dave Fisher , wrote:
> > > > > We should be sure to track and then highlight API changes in release 
> > > > > documents. API changes should be held until the next major version 
> > > > > (now 2.12) and be documented with that release. I think we need to be 
> > > > > explicit in our GitHub PR template. I don’t have a suggested edit 
> > > > > yet, but the idea is to add text about 1. How the PR changes the API 
> > > > > 2. Which PIP authorizes it

Re: [VOTE] Pulsar Release 2.11.0 Candidate-2

[PengHui Li]

> I'm wondering whether affecting the resource quota. Could you confirm
that?

Hmmm, I haven't heard of anyone using this feature.
I think it should be ok for a standalone.

Penghui

On Wed, Dec 7, 2022 at 1:33 PM Zixuan Liu  wrote:

> > If it only affects standalone. I think it’s ok.
>
> Right.
>
> > For standalone, multiple bundles help nothing, right?
>
> I'm wondering whether affecting the resource quota. Could you confirm that?
>
> Thanks,
> Zixuan
>
> PengHui Li  于2022年12月7日周三 12:53写道：
>
> > Hi Zixuan,
> >
> > If it only affects standalone. I think it’s ok.
> > For standalone, multiple bundles help nothing, right?
> > No rebalance will happen for a standalone.
> >
> > Thanks,
> > Penghui
> >
> > > On Dec 7, 2022, at 11:23, Yunze Xu 
> wrote:
> > >
> > > The change of a default value is acceptable in a major release. But
> > > since it's changed back in the next 2.12 release, it could be a little
> > > confusing. My perspective is to include this PR in the 2.11.0 release.
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Wed, Dec 7, 2022 at 11:00 AM Zixuan Liu  wrote:
> > >>
> > >> Pulsar 2.11 standalone breaks the bundle of namespace policy. I'm
> > wondering
> > >> whether blocking the Pulsar 2.11 release.
> > >>
> > >> See https://github.com/apache/pulsar/pull/18755
> > >>
> > >> Thanks,
> > >> Zixuan
> > >>
> > >> Enrico Olivelli  于2022年12月6日周二 21:26写道：
> > >>
> > >>> +1 (binding)
> > >>> - verified checksums, digests
> > >>> - built from sources
> > >>> - tested the docker image built from sources and the docker image
> > >>> provided as convenience with the VOTE
> > >>> - run successfully the Jakarta JMS 2.0 TCK against those two docker
> > images
> > >>>
> > >>> My problem with the JMS TCK is that the behaviour of "delete topic"
> > >>> with "force=true" changed, and now if the topic does not exist we get
> > >>> a 404 error, in Pulsar 2.10.x the response code was 200
> > >>> I think that this behaviour change is acceptable in a major release,
> > >>> and that actually the new behaviour is more consistent.
> > >>>
> > >>> More details here:
> > >>> https://github.com/datastax/pulsar-jms/pull/101
> > >>>
> > >>> Thank you for driving the release
> > >>>
> > >>> Enrico
> > >>>
> > >>> Il giorno lun 5 dic 2022 alle ore 16:21 Enrico Olivelli
> > >>>  ha scritto:
> > 
> >  FYI I am investigating some errors I see while running the Jakarta
> JMS
> >  TCK against a Pulsar 2.11.0rc2 server with the provided docker
> images.
> > 
> >  I still can't understand the problem, so I will keep you posted.
> > 
> >  Please hold on
> > 
> >  Enrico
> > 
> >  Il giorno dom 4 dic 2022 alle ore 19:13 Christophe Bornet
> >   ha scritto:
> > >
> > > +1 (non-binding)
> > >
> > > - Start docker image standalone
> > > - Test HTTP Sink
> > > - Test Transformation Function
> > >
> > > Best regards
> > >
> > > Christophe
> > >
> > > Le lun. 28 nov. 2022 à 13:57, guo jiwei  a
> > >>> écrit :
> > >
> > >> This is the second release candidate for Apache Pulsar, version
> > >>> 2.11.0.
> > >>
> > >> This release contains 1574 commits by 64 contributors.
> > >>
> > >>>
> https://github.com/apache/pulsar/compare/v2.10.2...v2.11.0-candidate-2
> > >>
> > >> CI for this release candidate
> > >> https://github.com/Technoboy-/pulsar/pull/14
> > >>
> > >> *** 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.11.0-candidate-2
> > >>
> > >> SHA-512 checksums:
> > >>
> > >>
> > >>
> > >>>
> >
> 199eb731bad0635fbc0388adf090e8c60ce189634e6b1692a12cfdf43f15347371d79c42d040b91dd7b2d0302061ad48bff850638e3bb48540ab24908792dd5e
> > >>
> > >> ./apache-pulsar-2.11.0-bin.tar.gz
> > >>
> > >>
> > >>
> > >>>
> >
> 035d5a656cdd4c2430ae4f7c4fef952ad05e432219a64474fcfaa097fcc7ad6cd76fd82b77e91d667e0ec8495c35fc08a5bb25a54058ccdfaf4072a22b94f6d7
> > >>
> > >> ./apache-pulsar-2.11.0-src.tar.gz
> > >>
> > >> Maven staging repo:
> > >>
> > >>>
> > https://repository.apache.org/content/repositories/orgapachepulsar-1192/
> > >> <
> > >>>
> > https://repository.apache.org/content/repositories/orgapachepulsar-1190/
> >
> > >>
> > >> The tag to be voted upon:
> > >> v2.11.0-candidate-2 (c0a823a242a834dac35b9a6fcd6a2064a0e4bfb5)
> > >> https://github.com/apache/pulsar/releases/tag/v2.11.0-candidate-2
> > >>
> > >> 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:/

Re: [DISCUSS] Proposal required for Admin API/CLI and metrics changes

[Haiting Jiang]

+1 for enforcing the PIP procedures.

> And the CI can try to add labels `doc required` or `wants/proposal`
> according to the list selections.

Is it possible that the CI can check if there is a "voted" PIP linking
to this PR.
And the label can be manually added by committers if the PR author
missed checking the boxes.

Thanks,
Haiting

On Wed, Dec 7, 2022 at 4:07 PM PengHui Li  wrote:
>
> > I agree a proposal would be better before adding a PR. But the
> document part must be a part of such a proposal.
>
> Make sense. It looks like we should have a checklist for the proposal.
> The documentation changes should be listed in the proposal.
>
> > Can the PR template/GitHub process check that if either the api changes
> and doc-required are checked both are checked with textual information
> provided?
>
> It's a good idea.
> I haven't tried, but it looks like it's possible.
> We have this list:
>
> ```
> ### Does this pull request potentially affect one of the following parts:
>
> *If the box was checked, please highlight the changes*
>
> - [ ] Dependencies (add or upgrade a dependency)
> - [ ] The public API
> - [ ] The schema
> - [ ] The default values of configurations
> - [ ] The binary protocol
> - [ ] The REST endpoints
> - [ ] The admin CLI options
> - [ ] Anything that affects deployment
> ```
>
> And the CI can try to add labels `doc required` or `wants/proposal`
> according to the
> list selections.
>
> And we can add `The metrics` item to the list.
>
> Thanks,
> Penghui
>
> On Wed, Dec 7, 2022 at 1:52 PM Dave Fisher  wrote:
>
> >
> >
> > Sent from my iPhone
> >
> > > On Dec 6, 2022, at 9:45 PM, Yunze Xu 
> > wrote:
> > >
> > > Hi Penghui,
> > >
> > >> But maybe some are missed.
> > >
> > > That's the point. Each PR that adds or modifies a metric item must be
> > > labeled with "doc-required" and the related documents should be added.
> > > However, these PRs are nearly all labeled with "doc-not-needed".
> > >
> > > I agree a proposal would be better before adding a PR. But the
> > > document part must be a part of such a proposal.
> >
> > Can the PR template/GitHub process check that if either the api changes
> > and doc-required are checked both are checked with textual information
> > provided?
> >
> > Best,
> > Dave
> > >
> > > Thanks,
> > > Yunze
> > >
> > >> On Wed, Dec 7, 2022 at 11:48 AM PengHui Li  wrote:
> > >>
> > >> Hi Yunze,
> > >>
> > >> All the metrics are listed here
> > >> https://pulsar.apache.org/docs/2.10.x/reference-metrics/
> > >>
> > >> But maybe some are missed.
> > >>
> > >> Thanks,
> > >> Penghui
> > >>
> > >> On Wed, Dec 7, 2022 at 11:46 AM Yunze Xu 
> > >> wrote:
> > >>
> > >>> I agree. It should have required the PIP.
> > >>>
> > >>> I have another question. Is there any document to describe these
> > >>> metrics? I think the metrics body should be documented well to avoid
> > >>> breaking changes. Some external applications might parse the metrics
> > >>> according to a specific structure.
> > >>>
> > >>> Thanks,
> > >>> Yunze
> > >>>
> > >>> On Wed, Dec 7, 2022 at 11:38 AM PengHui Li  wrote:
> > 
> >  Hi all,
> > 
> >  I would like to start a discussion about requiring a proposal for
> > Admin
> >  API/CLI
> >  and metrics changes.
> > 
> >  Here are some recent examples that changed the Admin API but without
> >  proposals.
> >  I just checked the commit logs. Maybe some have a proposal. Just
> > forgot
> > >>> to
> >  add
> >  the proposal link to the PR.
> > 
> >  https://github.com/apache/pulsar/pull/18218
> >  https://github.com/apache/pulsar/pull/17153
> >  https://github.com/apache/pulsar/pull/16167
> >  https://github.com/apache/pulsar/pull/14930
> >  https://github.com/apache/pulsar/pull/17337
> > 
> >  And here are metrics-related proposals. But looks like we don't have a
> >  clear rule
> >  for this part (the proposal is required or not)
> > 
> >  https://github.com/apache/pulsar/issues/18319
> >  https://github.com/apache/pulsar/issues/18560
> > 
> >  As more and more users are using Pulsar in production.
> >  But the Admin API changes and metrics changes have
> >  not required a proposal. This may pose a risk to users.
> >  The proposal will have better visibility, and voting is required.
> > 
> >  And actually, all the public API changes are proposals required.
> > 
> > >>>
> > https://github.com/apache/pulsar/blob/master/wiki/proposals/PIP.md#when-is-a-pip-required
> >  But in fact, this is not strictly enforced.
> > 
> >  Is it time to require a proposal for Admin API/CLI and metrics
> > changes?
> > 
> >  Thanks,
> >  Penghui
> > >>>
> >
> >

Re: [DISCUSS] How to handle broker public API changes

[Nicolò Boschi]

>
> The root cause is that we don't have an API abstraction for the
> pulsar-broker module


+1 I think that's reasonable to think about the pulsar-broker module as
internal and to not take care of retrocompatibility.

If we have the desire to expose the broker service classes in a
compatible way, we'll need to provide abstracted APIs for that.
Applications that embed the pulsar-broker dependency should be aware that
signatures may change even in patch releases and there's no compatibility
guarantee.

Do we explain to users how to add the broker dependency in the doc? If so,
we could add a note there.



Nicolò Boschi


Il giorno mer 7 dic 2022 alle ore 09:08 Haiting Jiang <
jianghait...@gmail.com> ha scritto:

> Hi all,
>
> We already have working procedures to change the public API, like PIP
> , mail-discussion and the PR templates.
> From what I understand, the problem is more like how to provide a
> clear and proper definition of "Broker Public API".
> I believe it's the reason why PIP-136 updated the method signature and
> no one finds it until now.
>
> And if we put the scope of "public API" to all the public methods in
> the broker modules, it would be definitely too broad and slow our
> development of other features.
>
> Thanks,
> Haiting
>
> On Wed, Dec 7, 2022 at 1:50 PM  wrote:
> >
> > > I'm afraid it's very hard to avoid these API changes. Take theprotocol
> handler as example, it could make use of nearly all modulesvia the
> `PulsarService` object. The cost to keep the compatibilitymight be high so
> that much legacy code could be left. For example,each time a new argument
> is added to a method, we have to add anoverload to keep the compatibility.
> It could be confusing to peoplewho don't know these extensions and they
> might wonder why an overloadis needed that is never used in the Pulsar's
> main repo.
> > Yes, I totally agree with your point. it's a trade-off,  I think we can
> hold this discussion until the ecosystem becomes bigger and this problem
> becomes more prominent.
> >
> > Best,
> > Mattison
> >
> > On Dec 7, 2022, 13:37 +0800, Yunze Xu ,
> wrote:
> > > I'm afraid it's very hard to avoid these API changes. Take the
> > > protocol handler as example, it could make use of nearly all modules
> > > via the `PulsarService` object. The cost to keep the compatibility
> > > might be high so that much legacy code could be left. For example,
> > > each time a new argument is added to a method, we have to add an
> > > overload to keep the compatibility. It could be confusing to people
> > > who don't know these extensions and they might wonder why an overload
> > > is needed that is never used in the Pulsar's main repo.
> > >
> > > The root cause is that we don't have an API abstraction for the
> > > pulsar-broker module, like the pulsar-client-api module to the
> > > pulsar-client mode. But it could be a huge project to add something
> > > like pulsar-broker-api.
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Wed, Dec 7, 2022 at 1:21 PM  wrote:
> > > >
> > > > > > It would help me understand if you would explain how apis were
> changed in this PR
> > > > Sorry, I explained above. it's a small break, maybe it just breaks
> some unit test mock, but it can be used as an example.
> > > > > > We should be sure to track and then highlight API changes in
> release documents.
> > > > > > API changes should be held until the next major version (now
> 2.12) and be documented with that release.
> > > > > > I think we need to be explicit in our GitHub PR template. I
> don’t have a suggested edit yet, but the idea is to add text about
> > > > > > 1. How the PR changes the API2. Which PIP authorizes it
> > > > +1 for an awesome idea.
> > > >
> > > > Am I just wondering if we can avoid breaking it? maybe we can give
> the old method a @Deprecated?
> > > >
> > > > Best,
> > > > Mattison
> > > > On Dec 7, 2022, 12:56 +0800, Dave Fisher ,
> wrote:
> > > > > > We should be sure to track and then highlight API changes in
> release documents. API changes should be held until the next major version
> (now 2.12) and be documented with that release. I think we need to be
> explicit in our GitHub PR template. I don’t have a suggested edit yet, but
> the idea is to add text about 1. How the PR changes the API 2. Which PIP
> authorizes it
>

[GitHub] [pulsar] nicoloboschi added a comment to the discussion: connect to broker in standalone mode via Kubernetes

[GitBox]

GitHub user nicoloboschi added a comment to the discussion: connect to broker 
in standalone mode via Kubernetes

In kubernetes you should use a 
[Service](https://kubernetes.io/docs/concepts/services-networking/service/) 
resource for manage networking and put it in "front" of the pulsar pod. 
Then the producer and consumer will have to point to the service name. 

For example you can create a service like this
```
apiVersion: v1
kind: Service
metadata:
  name: pulsar-service
spec:
  clusterIP: None
  selector:
app: pulsar
  ports:
- name: client
  port: 6650
- name: admin
  port: 8080
```

Assuming that your pod matches the label app=pulsar, then the producer and 
consumer will have to point to pulsar://pulsar-service:6650 (pulsar protocol) 
and http://pulsar-service:8080 (pulsar admin)

Another suggestion is to use a deployment instead of a raw pod.

Btw, for Pulsar in Kubernetes it's suggested to use a proper deployment process 
by using the helm chart or an operator.
At the moment there's a [Apache Pulsar Helm 
Chart](https://pulsar.apache.org/docs/2.10.x/helm-overview/)


GitHub link: 
https://github.com/apache/pulsar/discussions/18772#discussioncomment-4330831


This is an automatically sent email for dev@pulsar.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@pulsar.apache.org

[DISCUSS][PIP-226] Add JWKS support for AuthenticationProviderToken

[Zixuan Liu]

Hi all,

I made a PIP to discuss: https://github.com/apache/pulsar/issues/18798.

Thanks,
Zixuan

[DISCUSS] PIP-227: New API for closing the consumer after waiting for the job to complete

[Jie crossover]

Hi, pulsar community,

I’ve opened a PIP to discuss: PIP-227: New API for closing the consumer
after waiting for the job to complete.

The PIP link: https://github.com/apache/pulsar/issues/18799

Thanks.
-- 
Best Regards！
crossoverJie

Re: [VOTE] Pulsar Release 2.11.0 Candidate-2

[Zixuan Liu]

Ok, sounds good.

Thanks,
Zixuan

PengHui Li  于2022年12月7日周三 16:10写道：

> > I'm wondering whether affecting the resource quota. Could you confirm
> that?
>
> Hmmm, I haven't heard of anyone using this feature.
> I think it should be ok for a standalone.
>
> Penghui
>
> On Wed, Dec 7, 2022 at 1:33 PM Zixuan Liu  wrote:
>
> > > If it only affects standalone. I think it’s ok.
> >
> > Right.
> >
> > > For standalone, multiple bundles help nothing, right?
> >
> > I'm wondering whether affecting the resource quota. Could you confirm
> that?
> >
> > Thanks,
> > Zixuan
> >
> > PengHui Li  于2022年12月7日周三 12:53写道：
> >
> > > Hi Zixuan,
> > >
> > > If it only affects standalone. I think it’s ok.
> > > For standalone, multiple bundles help nothing, right?
> > > No rebalance will happen for a standalone.
> > >
> > > Thanks,
> > > Penghui
> > >
> > > > On Dec 7, 2022, at 11:23, Yunze Xu 
> > wrote:
> > > >
> > > > The change of a default value is acceptable in a major release. But
> > > > since it's changed back in the next 2.12 release, it could be a
> little
> > > > confusing. My perspective is to include this PR in the 2.11.0
> release.
> > > >
> > > > Thanks,
> > > > Yunze
> > > >
> > > > On Wed, Dec 7, 2022 at 11:00 AM Zixuan Liu 
> wrote:
> > > >>
> > > >> Pulsar 2.11 standalone breaks the bundle of namespace policy. I'm
> > > wondering
> > > >> whether blocking the Pulsar 2.11 release.
> > > >>
> > > >> See https://github.com/apache/pulsar/pull/18755
> > > >>
> > > >> Thanks,
> > > >> Zixuan
> > > >>
> > > >> Enrico Olivelli  于2022年12月6日周二 21:26写道：
> > > >>
> > > >>> +1 (binding)
> > > >>> - verified checksums, digests
> > > >>> - built from sources
> > > >>> - tested the docker image built from sources and the docker image
> > > >>> provided as convenience with the VOTE
> > > >>> - run successfully the Jakarta JMS 2.0 TCK against those two docker
> > > images
> > > >>>
> > > >>> My problem with the JMS TCK is that the behaviour of "delete topic"
> > > >>> with "force=true" changed, and now if the topic does not exist we
> get
> > > >>> a 404 error, in Pulsar 2.10.x the response code was 200
> > > >>> I think that this behaviour change is acceptable in a major
> release,
> > > >>> and that actually the new behaviour is more consistent.
> > > >>>
> > > >>> More details here:
> > > >>> https://github.com/datastax/pulsar-jms/pull/101
> > > >>>
> > > >>> Thank you for driving the release
> > > >>>
> > > >>> Enrico
> > > >>>
> > > >>> Il giorno lun 5 dic 2022 alle ore 16:21 Enrico Olivelli
> > > >>>  ha scritto:
> > > 
> > >  FYI I am investigating some errors I see while running the Jakarta
> > JMS
> > >  TCK against a Pulsar 2.11.0rc2 server with the provided docker
> > images.
> > > 
> > >  I still can't understand the problem, so I will keep you posted.
> > > 
> > >  Please hold on
> > > 
> > >  Enrico
> > > 
> > >  Il giorno dom 4 dic 2022 alle ore 19:13 Christophe Bornet
> > >   ha scritto:
> > > >
> > > > +1 (non-binding)
> > > >
> > > > - Start docker image standalone
> > > > - Test HTTP Sink
> > > > - Test Transformation Function
> > > >
> > > > Best regards
> > > >
> > > > Christophe
> > > >
> > > > Le lun. 28 nov. 2022 à 13:57, guo jiwei  a
> > > >>> écrit :
> > > >
> > > >> This is the second release candidate for Apache Pulsar, version
> > > >>> 2.11.0.
> > > >>
> > > >> This release contains 1574 commits by 64 contributors.
> > > >>
> > > >>>
> > https://github.com/apache/pulsar/compare/v2.10.2...v2.11.0-candidate-2
> > > >>
> > > >> CI for this release candidate
> > > >> https://github.com/Technoboy-/pulsar/pull/14
> > > >>
> > > >> *** 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.11.0-candidate-2
> > > >>
> > > >> SHA-512 checksums:
> > > >>
> > > >>
> > > >>
> > > >>>
> > >
> >
> 199eb731bad0635fbc0388adf090e8c60ce189634e6b1692a12cfdf43f15347371d79c42d040b91dd7b2d0302061ad48bff850638e3bb48540ab24908792dd5e
> > > >>
> > > >> ./apache-pulsar-2.11.0-bin.tar.gz
> > > >>
> > > >>
> > > >>
> > > >>>
> > >
> >
> 035d5a656cdd4c2430ae4f7c4fef952ad05e432219a64474fcfaa097fcc7ad6cd76fd82b77e91d667e0ec8495c35fc08a5bb25a54058ccdfaf4072a22b94f6d7
> > > >>
> > > >> ./apache-pulsar-2.11.0-src.tar.gz
> > > >>
> > > >> Maven staging repo:
> > > >>
> > > >>>
> > >
> https://repository.apache.org/content/repositories/orgapachepulsar-1192/
> > > >> <
> > > >>>
> > >
> https://repository.apache.org/content/repositories/orgapachepulsar-1190/
> > >
> > > >>
> > > >

Re: [VOTE] Pulsar Release 2.11.0 Candidate-2

[Nicolò Boschi]

I'm sorry but I think I've found a blocker issue.

pulsar-perf doesn't support jdk17.
I know client compatibility targets jdk8 but the image uses jdk17 and this
may be very annoying if pulsar-perf is not usable within the official
docker image.

btw I've send out the fix: https://github.com/apache/pulsar/pull/18806


Nicolò Boschi


Il giorno mer 7 dic 2022 alle ore 16:53 Zixuan Liu  ha
scritto:

> Ok, sounds good.
>
> Thanks,
> Zixuan
>
> PengHui Li  于2022年12月7日周三 16:10写道：
>
> > > I'm wondering whether affecting the resource quota. Could you confirm
> > that?
> >
> > Hmmm, I haven't heard of anyone using this feature.
> > I think it should be ok for a standalone.
> >
> > Penghui
> >
> > On Wed, Dec 7, 2022 at 1:33 PM Zixuan Liu  wrote:
> >
> > > > If it only affects standalone. I think it’s ok.
> > >
> > > Right.
> > >
> > > > For standalone, multiple bundles help nothing, right?
> > >
> > > I'm wondering whether affecting the resource quota. Could you confirm
> > that?
> > >
> > > Thanks,
> > > Zixuan
> > >
> > > PengHui Li  于2022年12月7日周三 12:53写道：
> > >
> > > > Hi Zixuan,
> > > >
> > > > If it only affects standalone. I think it’s ok.
> > > > For standalone, multiple bundles help nothing, right?
> > > > No rebalance will happen for a standalone.
> > > >
> > > > Thanks,
> > > > Penghui
> > > >
> > > > > On Dec 7, 2022, at 11:23, Yunze Xu 
> > > wrote:
> > > > >
> > > > > The change of a default value is acceptable in a major release. But
> > > > > since it's changed back in the next 2.12 release, it could be a
> > little
> > > > > confusing. My perspective is to include this PR in the 2.11.0
> > release.
> > > > >
> > > > > Thanks,
> > > > > Yunze
> > > > >
> > > > > On Wed, Dec 7, 2022 at 11:00 AM Zixuan Liu 
> > wrote:
> > > > >>
> > > > >> Pulsar 2.11 standalone breaks the bundle of namespace policy. I'm
> > > > wondering
> > > > >> whether blocking the Pulsar 2.11 release.
> > > > >>
> > > > >> See https://github.com/apache/pulsar/pull/18755
> > > > >>
> > > > >> Thanks,
> > > > >> Zixuan
> > > > >>
> > > > >> Enrico Olivelli  于2022年12月6日周二 21:26写道：
> > > > >>
> > > > >>> +1 (binding)
> > > > >>> - verified checksums, digests
> > > > >>> - built from sources
> > > > >>> - tested the docker image built from sources and the docker image
> > > > >>> provided as convenience with the VOTE
> > > > >>> - run successfully the Jakarta JMS 2.0 TCK against those two
> docker
> > > > images
> > > > >>>
> > > > >>> My problem with the JMS TCK is that the behaviour of "delete
> topic"
> > > > >>> with "force=true" changed, and now if the topic does not exist we
> > get
> > > > >>> a 404 error, in Pulsar 2.10.x the response code was 200
> > > > >>> I think that this behaviour change is acceptable in a major
> > release,
> > > > >>> and that actually the new behaviour is more consistent.
> > > > >>>
> > > > >>> More details here:
> > > > >>> https://github.com/datastax/pulsar-jms/pull/101
> > > > >>>
> > > > >>> Thank you for driving the release
> > > > >>>
> > > > >>> Enrico
> > > > >>>
> > > > >>> Il giorno lun 5 dic 2022 alle ore 16:21 Enrico Olivelli
> > > > >>>  ha scritto:
> > > > 
> > > >  FYI I am investigating some errors I see while running the
> Jakarta
> > > JMS
> > > >  TCK against a Pulsar 2.11.0rc2 server with the provided docker
> > > images.
> > > > 
> > > >  I still can't understand the problem, so I will keep you posted.
> > > > 
> > > >  Please hold on
> > > > 
> > > >  Enrico
> > > > 
> > > >  Il giorno dom 4 dic 2022 alle ore 19:13 Christophe Bornet
> > > >   ha scritto:
> > > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > - Start docker image standalone
> > > > > - Test HTTP Sink
> > > > > - Test Transformation Function
> > > > >
> > > > > Best regards
> > > > >
> > > > > Christophe
> > > > >
> > > > > Le lun. 28 nov. 2022 à 13:57, guo jiwei 
> a
> > > > >>> écrit :
> > > > >
> > > > >> This is the second release candidate for Apache Pulsar,
> version
> > > > >>> 2.11.0.
> > > > >>
> > > > >> This release contains 1574 commits by 64 contributors.
> > > > >>
> > > > >>>
> > > https://github.com/apache/pulsar/compare/v2.10.2...v2.11.0-candidate-2
> > > > >>
> > > > >> CI for this release candidate
> > > > >> https://github.com/Technoboy-/pulsar/pull/14
> > > > >>
> > > > >> *** 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.11.0-candidate-2
> > > > >>
> > > > >> SHA-512 checksums:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>
> > > >
> > >
> >
> 199eb7

Re: [VOTE] Pulsar Release 2.11.0 Candidate-2

[Nicolò Boschi]

Just realized that the error doesn't block the producer but it's only
related to some DNS caching optimizations.
I believe we can proceed with the current rc

Nicolò Boschi


Il giorno mer 7 dic 2022 alle ore 17:40 Nicolò Boschi 
ha scritto:

> I'm sorry but I think I've found a blocker issue.
>
> pulsar-perf doesn't support jdk17.
> I know client compatibility targets jdk8 but the image uses jdk17 and this
> may be very annoying if pulsar-perf is not usable within the official
> docker image.
>
> btw I've send out the fix: https://github.com/apache/pulsar/pull/18806
>
>
> Nicolò Boschi
>
>
> Il giorno mer 7 dic 2022 alle ore 16:53 Zixuan Liu  ha
> scritto:
>
>> Ok, sounds good.
>>
>> Thanks,
>> Zixuan
>>
>> PengHui Li  于2022年12月7日周三 16:10写道：
>>
>> > > I'm wondering whether affecting the resource quota. Could you confirm
>> > that?
>> >
>> > Hmmm, I haven't heard of anyone using this feature.
>> > I think it should be ok for a standalone.
>> >
>> > Penghui
>> >
>> > On Wed, Dec 7, 2022 at 1:33 PM Zixuan Liu  wrote:
>> >
>> > > > If it only affects standalone. I think it’s ok.
>> > >
>> > > Right.
>> > >
>> > > > For standalone, multiple bundles help nothing, right?
>> > >
>> > > I'm wondering whether affecting the resource quota. Could you confirm
>> > that?
>> > >
>> > > Thanks,
>> > > Zixuan
>> > >
>> > > PengHui Li  于2022年12月7日周三 12:53写道：
>> > >
>> > > > Hi Zixuan,
>> > > >
>> > > > If it only affects standalone. I think it’s ok.
>> > > > For standalone, multiple bundles help nothing, right?
>> > > > No rebalance will happen for a standalone.
>> > > >
>> > > > Thanks,
>> > > > Penghui
>> > > >
>> > > > > On Dec 7, 2022, at 11:23, Yunze Xu 
>> > > wrote:
>> > > > >
>> > > > > The change of a default value is acceptable in a major release.
>> But
>> > > > > since it's changed back in the next 2.12 release, it could be a
>> > little
>> > > > > confusing. My perspective is to include this PR in the 2.11.0
>> > release.
>> > > > >
>> > > > > Thanks,
>> > > > > Yunze
>> > > > >
>> > > > > On Wed, Dec 7, 2022 at 11:00 AM Zixuan Liu 
>> > wrote:
>> > > > >>
>> > > > >> Pulsar 2.11 standalone breaks the bundle of namespace policy. I'm
>> > > > wondering
>> > > > >> whether blocking the Pulsar 2.11 release.
>> > > > >>
>> > > > >> See https://github.com/apache/pulsar/pull/18755
>> > > > >>
>> > > > >> Thanks,
>> > > > >> Zixuan
>> > > > >>
>> > > > >> Enrico Olivelli  于2022年12月6日周二 21:26写道：
>> > > > >>
>> > > > >>> +1 (binding)
>> > > > >>> - verified checksums, digests
>> > > > >>> - built from sources
>> > > > >>> - tested the docker image built from sources and the docker
>> image
>> > > > >>> provided as convenience with the VOTE
>> > > > >>> - run successfully the Jakarta JMS 2.0 TCK against those two
>> docker
>> > > > images
>> > > > >>>
>> > > > >>> My problem with the JMS TCK is that the behaviour of "delete
>> topic"
>> > > > >>> with "force=true" changed, and now if the topic does not exist
>> we
>> > get
>> > > > >>> a 404 error, in Pulsar 2.10.x the response code was 200
>> > > > >>> I think that this behaviour change is acceptable in a major
>> > release,
>> > > > >>> and that actually the new behaviour is more consistent.
>> > > > >>>
>> > > > >>> More details here:
>> > > > >>> https://github.com/datastax/pulsar-jms/pull/101
>> > > > >>>
>> > > > >>> Thank you for driving the release
>> > > > >>>
>> > > > >>> Enrico
>> > > > >>>
>> > > > >>> Il giorno lun 5 dic 2022 alle ore 16:21 Enrico Olivelli
>> > > > >>>  ha scritto:
>> > > > 
>> > > >  FYI I am investigating some errors I see while running the
>> Jakarta
>> > > JMS
>> > > >  TCK against a Pulsar 2.11.0rc2 server with the provided docker
>> > > images.
>> > > > 
>> > > >  I still can't understand the problem, so I will keep you
>> posted.
>> > > > 
>> > > >  Please hold on
>> > > > 
>> > > >  Enrico
>> > > > 
>> > > >  Il giorno dom 4 dic 2022 alle ore 19:13 Christophe Bornet
>> > > >   ha scritto:
>> > > > >
>> > > > > +1 (non-binding)
>> > > > >
>> > > > > - Start docker image standalone
>> > > > > - Test HTTP Sink
>> > > > > - Test Transformation Function
>> > > > >
>> > > > > Best regards
>> > > > >
>> > > > > Christophe
>> > > > >
>> > > > > Le lun. 28 nov. 2022 à 13:57, guo jiwei 
>> a
>> > > > >>> écrit :
>> > > > >
>> > > > >> This is the second release candidate for Apache Pulsar,
>> version
>> > > > >>> 2.11.0.
>> > > > >>
>> > > > >> This release contains 1574 commits by 64 contributors.
>> > > > >>
>> > > > >>>
>> > >
>> https://github.com/apache/pulsar/compare/v2.10.2...v2.11.0-candidate-2
>> > > > >>
>> > > > >> CI for this release candidate
>> > > > >> https://github.com/Technoboy-/pulsar/pull/14
>> > > > >>
>> > > > >> *** Please download, test and vote on this release. This vote
>> > will
>> > > > >>> stay
>> > > > >> open
>> > > > >> for at least 72 hours ***
>> > > > >>
>> > > >

Re: [DISCUSS] PIP-227: New API for closing the consumer after waiting for the job to complete

[丛搏]

Hi, Jie:
I think it's better to leave it to user handle. We try not to add APIs that
users can handle themselves. And I don't think there are many scenarios
using this API, which brings about higher complexity. I tend to add a new
interface beforeClose() in ConsumerInterceptor to allow users to customiz.
Thanks,
bo

Jie crossover 于2022年12月7日 周三20:05写道：

> Hi, pulsar community,
>
> I’ve opened a PIP to discuss: PIP-227: New API for closing the consumer
> after waiting for the job to complete.
>
> The PIP link: https://github.com/apache/pulsar/issues/18799
>
> Thanks.
> --
> Best Regards！
> crossoverJie
>

[VOTE] Reactive Java client for Apache Pulsar 0.1.0 Candidate 1

[Christophe Bornet]

Following PIP-205: Reactive Java client for Apache Pulsar (
https://github.com/apache/pulsar/issues/17335), this is the first release
candidate for the Reactive Java client for Apache Pulsar, version 0.1.0.

Please see the GitHub repo for the sources:
https://github.com/apache/pulsar-client-reactive

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

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

The tag to be voted upon:
v0.1.0-candidate-1 (052a219334f68d9c8f050b4331c061c2801d92f6)
https://github.com/apache/pulsar-client-reactive/releases/tag/v0.1.0-candidate-1

Please download the source package, and follow the README to build
and run the Reactive Java client for Apache Pulsar.

Best regards

Christophe Bornet (cbornet)

Re: [VOTE] Reactive Java client for Apache Pulsar 0.1.0 Candidate 1

[Lari Hotari]

Since this is a new module, it's the first time we are setting up the release 
process.
I have pushed the sources for voting to this location:

https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-reactive-0.1.0-candidate-1/

The sources are the same as in the opening voting mail that Christophe sent for 
pulsar-client-reactive v0.1.0-candidate-1 
(052a219334f68d9c8f050b4331c061c2801d92f6).

I have written release validation instructions to pulsar-client-reactive wiki 
page, 
https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
 .

Please help validate the release.

-Lari

On 2022/12/07 19:09:23 Christophe Bornet wrote:
> Following PIP-205: Reactive Java client for Apache Pulsar (
> https://github.com/apache/pulsar/issues/17335), this is the first release
> candidate for the Reactive Java client for Apache Pulsar, version 0.1.0.
> 
> Please see the GitHub repo for the sources:
> https://github.com/apache/pulsar-client-reactive
> 
> *** 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.
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1194/
> 
> The tag to be voted upon:
> v0.1.0-candidate-1 (052a219334f68d9c8f050b4331c061c2801d92f6)
> https://github.com/apache/pulsar-client-reactive/releases/tag/v0.1.0-candidate-1
> 
> Please download the source package, and follow the README to build
> and run the Reactive Java client for Apache Pulsar.
> 
> Best regards
> 
> Christophe Bornet (cbornet)
> 

Re: [VOTE] Reactive Java client for Apache Pulsar 0.1.0 Candidate 1

[Lari Hotari]

+1, binding

- sources, signature and checksums validated
- Staged maven artifacts validated with a simple pulsar-client-reactive 
application.
(followed 
https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
 for validation)

-Lari

On 2022/12/07 19:09:23 Christophe Bornet wrote:
> Following PIP-205: Reactive Java client for Apache Pulsar (
> https://github.com/apache/pulsar/issues/17335), this is the first release
> candidate for the Reactive Java client for Apache Pulsar, version 0.1.0.
> 
> Please see the GitHub repo for the sources:
> https://github.com/apache/pulsar-client-reactive
> 
> *** 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.
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1194/
> 
> The tag to be voted upon:
> v0.1.0-candidate-1 (052a219334f68d9c8f050b4331c061c2801d92f6)
> https://github.com/apache/pulsar-client-reactive/releases/tag/v0.1.0-candidate-1
> 
> Please download the source package, and follow the README to build
> and run the Reactive Java client for Apache Pulsar.
> 
> Best regards
> 
> Christophe Bornet (cbornet)
> 

Re: [VOTE] Reactive Java client for Apache Pulsar 0.1.0 Candidate 1

[Lari Hotari]

After consulting with Dave Fisher, I'm ending this first vote since it didn't 
contain all necessary details (the source artifact location and checksum).

This vote thread is ended and I'll re-open a new thread for the actual vote.

-Lari


On 2022/12/07 19:09:23 Christophe Bornet wrote:
> Following PIP-205: Reactive Java client for Apache Pulsar (
> https://github.com/apache/pulsar/issues/17335), this is the first release
> candidate for the Reactive Java client for Apache Pulsar, version 0.1.0.
> 
> Please see the GitHub repo for the sources:
> https://github.com/apache/pulsar-client-reactive
> 
> *** 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.
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1194/
> 
> The tag to be voted upon:
> v0.1.0-candidate-1 (052a219334f68d9c8f050b4331c061c2801d92f6)
> https://github.com/apache/pulsar-client-reactive/releases/tag/v0.1.0-candidate-1
> 
> Please download the source package, and follow the README to build
> and run the Reactive Java client for Apache Pulsar.
> 
> Best regards
> 
> Christophe Bornet (cbornet)
> 

[VOTE] Reactive Java client for Apache Pulsar 0.1.0 Candidate 1, #2 vote

[Lari Hotari]

Following PIP-205: Reactive Java client for Apache Pulsar (
https://github.com/apache/pulsar/issues/17335), this is the first release
candidate for the Reactive Java client for Apache Pulsar, version 0.1.0.

*** 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 in the Maven repository
are provided for convenience.

Source files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-reactive-0.1.0-candidate-1/

SHA-512 checksums:
c10ec566d6f758b6a3c09f957e3e6005fdee8d8b9979b84cb33c9feae6fe28c84e198387fe0b92b6e1c697dd8e454b5a1b04565a74560a36259c35bfcfffccd2
  pulsar-client-reactive-0.1.0-candidate-1.tar.gz

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

The tag to be voted upon:
v0.1.0-candidate-1 (052a219334f68d9c8f050b4331c061c2801d92f6)
https://github.com/apache/pulsar-client-reactive/releases/tag/v0.1.0-candidate-1

Please download the source package, and follow detailed instructions for 
pulsar-client-reactive release validation at 
https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
 .

Best regards

Lari Hotari

Re: [VOTE] Reactive Java client for Apache Pulsar 0.1.0 Candidate 1, #2 vote

[Lari Hotari]

+1, binding

- sources, signature and checksums validated
  - sha512 checksum matches 
c10ec566d6f758b6a3c09f957e3e6005fdee8d8b9979b84cb33c9feae6fe28c84e198387fe0b92b6e1c697dd8e454b5a1b04565a74560a36259c35bfcfffccd2
  - signature is valid 
  - sources match git tag v0.1.0-candidate-1 
(052a219334f68d9c8f050b4331c061c2801d92f6)
- Staged maven artifacts validated with a simple pulsar-client-reactive 
application.
(followed 
https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
 for validation)

-Lari

On 2022/12/07 20:56:30 Lari Hotari wrote:
> Following PIP-205: Reactive Java client for Apache Pulsar (
> https://github.com/apache/pulsar/issues/17335), this is the first release
> candidate for the Reactive Java client for Apache Pulsar, version 0.1.0.
> 
> *** 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 in the Maven 
> repository
> are provided for convenience.
> 
> Source files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-reactive-0.1.0-candidate-1/
> 
> SHA-512 checksums:
> c10ec566d6f758b6a3c09f957e3e6005fdee8d8b9979b84cb33c9feae6fe28c84e198387fe0b92b6e1c697dd8e454b5a1b04565a74560a36259c35bfcfffccd2
>   pulsar-client-reactive-0.1.0-candidate-1.tar.gz
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1194/
> 
> The tag to be voted upon:
> v0.1.0-candidate-1 (052a219334f68d9c8f050b4331c061c2801d92f6)
> https://github.com/apache/pulsar-client-reactive/releases/tag/v0.1.0-candidate-1
> 
> Please download the source package, and follow detailed instructions for 
> pulsar-client-reactive release validation at 
> https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
>  .
> 
> Best regards
> 
> Lari Hotari
> 

Re: [VOTE] Reactive Java client for Apache Pulsar 0.1.0 Candidate 1, #2 vote

[Dave Fisher]

Hi -

-1 (binding)

1. grade-wrapper.jar is a compiled binary and is not allowed. You can provide a 
script to be run to download it. See issues.apache.org/jira/browse/CALCITE-4575

2. NOTICE file is missing. See apache.org/legal/src-headers.html#notice

3. A few of the *.gradle files are missing AL2 headers. If they have a 
different license they should have the correct header and then the NOTICE may 
need to include any required disclosure.

Otherwise the signatures and checksums are valid.

Regards,
Dave

> On Dec 7, 2022, at 12:56 PM, Lari Hotari  wrote:
> 
> Following PIP-205: Reactive Java client for Apache Pulsar (
> https://github.com/apache/pulsar/issues/17335), this is the first release
> candidate for the Reactive Java client for Apache Pulsar, version 0.1.0.
> 
> *** 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 in the Maven 
> repository
> are provided for convenience.
> 
> Source files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-reactive-0.1.0-candidate-1/
> 
> SHA-512 checksums:
> c10ec566d6f758b6a3c09f957e3e6005fdee8d8b9979b84cb33c9feae6fe28c84e198387fe0b92b6e1c697dd8e454b5a1b04565a74560a36259c35bfcfffccd2
>   pulsar-client-reactive-0.1.0-candidate-1.tar.gz
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1194/
> 
> The tag to be voted upon:
> v0.1.0-candidate-1 (052a219334f68d9c8f050b4331c061c2801d92f6)
> https://github.com/apache/pulsar-client-reactive/releases/tag/v0.1.0-candidate-1
> 
> Please download the source package, and follow detailed instructions for 
> pulsar-client-reactive release validation at 
> https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
>  .
> 
> Best regards
> 
> Lari Hotari

Re: [VOTE] Reactive Java client for Apache Pulsar 0.1.0 Candidate 1, #2 vote

[Christophe Bornet]

Good points Dave.
Thanks for your feedback.

Le mer. 7 déc. 2022 à 22:43, Dave Fisher  a écrit :

> Hi -
>
> -1 (binding)
>
> 1. grade-wrapper.jar is a compiled binary and is not allowed. You can
> provide a script to be run to download it. See
> issues.apache.org/jira/browse/CALCITE-4575
>
> 2. NOTICE file is missing. See apache.org/legal/src-headers.html#notice
>
> 3. A few of the *.gradle files are missing AL2 headers. If they have a
> different license they should have the correct header and then the NOTICE
> may need to include any required disclosure.
>
> Otherwise the signatures and checksums are valid.
>
> Regards,
> Dave
>
> > On Dec 7, 2022, at 12:56 PM, Lari Hotari  wrote:
> >
> > Following PIP-205: Reactive Java client for Apache Pulsar (
> > https://github.com/apache/pulsar/issues/17335), this is the first
> release
> > candidate for the Reactive Java client for Apache Pulsar, version 0.1.0.
> >
> > *** 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 in the Maven
> repository
> > are provided for convenience.
> >
> > Source files:
> >
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-reactive-0.1.0-candidate-1/
> >
> > SHA-512 checksums:
> >
> c10ec566d6f758b6a3c09f957e3e6005fdee8d8b9979b84cb33c9feae6fe28c84e198387fe0b92b6e1c697dd8e454b5a1b04565a74560a36259c35bfcfffccd2
> pulsar-client-reactive-0.1.0-candidate-1.tar.gz
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachepulsar-1194/
> >
> > The tag to be voted upon:
> > v0.1.0-candidate-1 (052a219334f68d9c8f050b4331c061c2801d92f6)
> >
> https://github.com/apache/pulsar-client-reactive/releases/tag/v0.1.0-candidate-1
> >
> > Please download the source package, and follow detailed instructions for
> pulsar-client-reactive release validation at
> https://github.com/apache/pulsar-client-reactive/wiki/Release-process#release-validation
> .
> >
> > Best regards
> >
> > Lari Hotari
>
>

Re: [VOTE] Pulsar Release 2.11.0 Candidate-2

[Massimiliano Mirelli]

Hi,
I am running some long-lasting tests on this rc at the moment. Would it be
OK to close the vote EOW or could you give me another 20h?
Thank you,
Max

On Wed, 7 Dec 2022, 18:47 Nicolò Boschi,  wrote:

> Just realized that the error doesn't block the producer but it's only
> related to some DNS caching optimizations.
> I believe we can proceed with the current rc
>
> Nicolò Boschi
>
>
> Il giorno mer 7 dic 2022 alle ore 17:40 Nicolò Boschi <
> boschi1...@gmail.com>
> ha scritto:
>
> > I'm sorry but I think I've found a blocker issue.
> >
> > pulsar-perf doesn't support jdk17.
> > I know client compatibility targets jdk8 but the image uses jdk17 and
> this
> > may be very annoying if pulsar-perf is not usable within the official
> > docker image.
> >
> > btw I've send out the fix: https://github.com/apache/pulsar/pull/18806
> >
> >
> > Nicolò Boschi
> >
> >
> > Il giorno mer 7 dic 2022 alle ore 16:53 Zixuan Liu 
> ha
> > scritto:
> >
> >> Ok, sounds good.
> >>
> >> Thanks,
> >> Zixuan
> >>
> >> PengHui Li  于2022年12月7日周三 16:10写道：
> >>
> >> > > I'm wondering whether affecting the resource quota. Could you
> confirm
> >> > that?
> >> >
> >> > Hmmm, I haven't heard of anyone using this feature.
> >> > I think it should be ok for a standalone.
> >> >
> >> > Penghui
> >> >
> >> > On Wed, Dec 7, 2022 at 1:33 PM Zixuan Liu  wrote:
> >> >
> >> > > > If it only affects standalone. I think it’s ok.
> >> > >
> >> > > Right.
> >> > >
> >> > > > For standalone, multiple bundles help nothing, right?
> >> > >
> >> > > I'm wondering whether affecting the resource quota. Could you
> confirm
> >> > that?
> >> > >
> >> > > Thanks,
> >> > > Zixuan
> >> > >
> >> > > PengHui Li  于2022年12月7日周三 12:53写道：
> >> > >
> >> > > > Hi Zixuan,
> >> > > >
> >> > > > If it only affects standalone. I think it’s ok.
> >> > > > For standalone, multiple bundles help nothing, right?
> >> > > > No rebalance will happen for a standalone.
> >> > > >
> >> > > > Thanks,
> >> > > > Penghui
> >> > > >
> >> > > > > On Dec 7, 2022, at 11:23, Yunze Xu  >
> >> > > wrote:
> >> > > > >
> >> > > > > The change of a default value is acceptable in a major release.
> >> But
> >> > > > > since it's changed back in the next 2.12 release, it could be a
> >> > little
> >> > > > > confusing. My perspective is to include this PR in the 2.11.0
> >> > release.
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Yunze
> >> > > > >
> >> > > > > On Wed, Dec 7, 2022 at 11:00 AM Zixuan Liu 
> >> > wrote:
> >> > > > >>
> >> > > > >> Pulsar 2.11 standalone breaks the bundle of namespace policy.
> I'm
> >> > > > wondering
> >> > > > >> whether blocking the Pulsar 2.11 release.
> >> > > > >>
> >> > > > >> See https://github.com/apache/pulsar/pull/18755
> >> > > > >>
> >> > > > >> Thanks,
> >> > > > >> Zixuan
> >> > > > >>
> >> > > > >> Enrico Olivelli  于2022年12月6日周二 21:26写道：
> >> > > > >>
> >> > > > >>> +1 (binding)
> >> > > > >>> - verified checksums, digests
> >> > > > >>> - built from sources
> >> > > > >>> - tested the docker image built from sources and the docker
> >> image
> >> > > > >>> provided as convenience with the VOTE
> >> > > > >>> - run successfully the Jakarta JMS 2.0 TCK against those two
> >> docker
> >> > > > images
> >> > > > >>>
> >> > > > >>> My problem with the JMS TCK is that the behaviour of "delete
> >> topic"
> >> > > > >>> with "force=true" changed, and now if the topic does not exist
> >> we
> >> > get
> >> > > > >>> a 404 error, in Pulsar 2.10.x the response code was 200
> >> > > > >>> I think that this behaviour change is acceptable in a major
> >> > release,
> >> > > > >>> and that actually the new behaviour is more consistent.
> >> > > > >>>
> >> > > > >>> More details here:
> >> > > > >>> https://github.com/datastax/pulsar-jms/pull/101
> >> > > > >>>
> >> > > > >>> Thank you for driving the release
> >> > > > >>>
> >> > > > >>> Enrico
> >> > > > >>>
> >> > > > >>> Il giorno lun 5 dic 2022 alle ore 16:21 Enrico Olivelli
> >> > > > >>>  ha scritto:
> >> > > > 
> >> > > >  FYI I am investigating some errors I see while running the
> >> Jakarta
> >> > > JMS
> >> > > >  TCK against a Pulsar 2.11.0rc2 server with the provided
> docker
> >> > > images.
> >> > > > 
> >> > > >  I still can't understand the problem, so I will keep you
> >> posted.
> >> > > > 
> >> > > >  Please hold on
> >> > > > 
> >> > > >  Enrico
> >> > > > 
> >> > > >  Il giorno dom 4 dic 2022 alle ore 19:13 Christophe Bornet
> >> > > >   ha scritto:
> >> > > > >
> >> > > > > +1 (non-binding)
> >> > > > >
> >> > > > > - Start docker image standalone
> >> > > > > - Test HTTP Sink
> >> > > > > - Test Transformation Function
> >> > > > >
> >> > > > > Best regards
> >> > > > >
> >> > > > > Christophe
> >> > > > >
> >> > > > > Le lun. 28 nov. 2022 à 13:57, guo jiwei <
> techno...@apache.org>
> >> a
> >> > > > >>> écrit :
> >> > > > >
> >> > > > >> This is the second release candidate for Apac

[VOTE][PIP-225] Pulsar Functions fetch parameters from local config file.

[Yufei Zhang]

Hi all,

I'm starting the vote for PIP-225: Pulsar Functions fetch parameters from
local config file:
https://github.com/apache/pulsar/issues/18744

Here is the discussion thread:
https://lists.apache.org/thread/3m6z7jgn71nzd3ng3x73vsxvd4b1jjcp

The vote will be open for at least 3 days.

Cheers,
Yufei

Re: [DISCUSS] PIP-227: New API for closing the consumer after waiting for the job to complete

[PengHui Li]

Hi, Jie

One option is you can try to call consumer.pause() first.
Then the consumer will not increase flow permits.
No new messages will be dispatched to this consumer.

And you can continue to receive messages from
the buffer of the consumer. After all cached messages
consumed. You can close the consumer.

Thanks,
Penghui

On Thu, Dec 8, 2022 at 3:02 AM 丛搏  wrote:

> Hi, Jie:
> I think it's better to leave it to user handle. We try not to add APIs that
> users can handle themselves. And I don't think there are many scenarios
> using this API, which brings about higher complexity. I tend to add a new
> interface beforeClose() in ConsumerInterceptor to allow users to customiz.
> Thanks,
> bo
>
> Jie crossover 于2022年12月7日 周三20:05写道：
>
> > Hi, pulsar community,
> >
> > I’ve opened a PIP to discuss: PIP-227: New API for closing the consumer
> > after waiting for the job to complete.
> >
> > The PIP link: https://github.com/apache/pulsar/issues/18799
> >
> > Thanks.
> > --
> > Best Regards！
> > crossoverJie
> >
>

Re: [VOTE][PIP-225] Pulsar Functions fetch parameters from local config file.

[Rui Fu]

+1

Best,

Rui Fu
On Dec 8, 2022, 07:48 +0800, Yufei Zhang , wrote:
> Hi all,
>
> I'm starting the vote for PIP-225: Pulsar Functions fetch parameters from
> local config file:
> https://github.com/apache/pulsar/issues/18744
>
> Here is the discussion thread:
> https://lists.apache.org/thread/3m6z7jgn71nzd3ng3x73vsxvd4b1jjcp
>
> The vote will be open for at least 3 days.
>
> Cheers,
> Yufei

Re: [DISCUSS] PIP-227: New API for closing the consumer after waiting for the job to complete

[Jie crossover]

Thanks for the discussion.

Even though the `pause()` is called, when the processing logic is
asynchronous, the `acknowledge()` will still not be called, resulting in re-
consumed when the consumer is restarted.

The background here is that I found a problem similar to this issue
 while testing.

I agree with your points, there is also a bit of complexity found in the
implementation process.

So it's a good idea to leave the processing of this uncommon requirement to
the user.

Adding a new interface `beforeClose()` is a bit cleaner to implement.
Any other suggestions?
thx.
-- 
Best Regards！
crossoverJie


PengHui Li  于2022年12月8日周四 10:17写道：

> Hi, Jie
>
> One option is you can try to call consumer.pause() first.
> Then the consumer will not increase flow permits.
> No new messages will be dispatched to this consumer.
>
> And you can continue to receive messages from
> the buffer of the consumer. After all cached messages
> consumed. You can close the consumer.
>
> Thanks,
> Penghui
>
> On Thu, Dec 8, 2022 at 3:02 AM 丛搏  wrote:
>
> > Hi, Jie:
> > I think it's better to leave it to user handle. We try not to add APIs
> that
> > users can handle themselves. And I don't think there are many scenarios
> > using this API, which brings about higher complexity. I tend to add a new
> > interface beforeClose() in ConsumerInterceptor to allow users to
> customiz.
> > Thanks,
> > bo
> >
> > Jie crossover 于2022年12月7日 周三20:05写道：
> >
> > > Hi, pulsar community,
> > >
> > > I’ve opened a PIP to discuss: PIP-227: New API for closing the consumer
> > > after waiting for the job to complete.
> > >
> > > The PIP link: https://github.com/apache/pulsar/issues/18799
> > >
> > > Thanks.
> > > --
> > > Best Regards！
> > > crossoverJie
> > >
> >
>

Re: [VOTE] Pulsar Release 2.11.0 Candidate-2

[mattisonchao]

Hi, All

I found two regressions that need to block this release.

https://github.com/apache/pulsar/pull/18816
https://github.com/apache/pulsar/pull/18812


Best,
Mattison
On Dec 8, 2022, 07:15 +0800, Massimiliano Mirelli 
, wrote:
> Hi,
> I am running some long-lasting tests on this rc at the moment. Would it be
> OK to close the vote EOW or could you give me another 20h?
> Thank you,
> Max
>
> On Wed, 7 Dec 2022, 18:47 Nicolò Boschi,  wrote:
>
> > Just realized that the error doesn't block the producer but it's only
> > related to some DNS caching optimizations.
> > I believe we can proceed with the current rc
> >
> > Nicolò Boschi
> >
> >
> > Il giorno mer 7 dic 2022 alle ore 17:40 Nicolò Boschi <
> > boschi1...@gmail.com>
> > ha scritto:
> >
> > > > I'm sorry but I think I've found a blocker issue.
> > > >
> > > > pulsar-perf doesn't support jdk17.
> > > > I know client compatibility targets jdk8 but the image uses jdk17 and
> > this
> > > > may be very annoying if pulsar-perf is not usable within the official
> > > > docker image.
> > > >
> > > > btw I've send out the fix: https://github.com/apache/pulsar/pull/18806
> > > >
> > > >
> > > > Nicolò Boschi
> > > >
> > > >
> > > > Il giorno mer 7 dic 2022 alle ore 16:53 Zixuan Liu 
> > ha
> > > > scritto:
> > > >
> > > > >> Ok, sounds good.
> > > > >>
> > > > >> Thanks,
> > > > >> Zixuan
> > > > >>
> > > > >> PengHui Li  于2022年12月7日周三 16:10写道：
> > > > >>
> > > > > > >> > > I'm wondering whether affecting the resource quota. Could you
> > confirm
> > > > > >> > that?
> > > > > >> >
> > > > > >> > Hmmm, I haven't heard of anyone using this feature.
> > > > > >> > I think it should be ok for a standalone.
> > > > > >> >
> > > > > >> > Penghui
> > > > > >> >
> > > > > >> > On Wed, Dec 7, 2022 at 1:33 PM Zixuan Liu  
> > > > > >> > wrote:
> > > > > >> >
> > > > > > > >> > > > If it only affects standalone. I think it’s ok.
> > > > > > >> > >
> > > > > > >> > > Right.
> > > > > > >> > >
> > > > > > > >> > > > For standalone, multiple bundles help nothing, right?
> > > > > > >> > >
> > > > > > >> > > I'm wondering whether affecting the resource quota. Could you
> > confirm
> > > > > >> > that?
> > > > > > >> > >
> > > > > > >> > > Thanks,
> > > > > > >> > > Zixuan
> > > > > > >> > >
> > > > > > >> > > PengHui Li  于2022年12月7日周三 12:53写道：
> > > > > > >> > >
> > > > > > > >> > > > Hi Zixuan,
> > > > > > > >> > > >
> > > > > > > >> > > > If it only affects standalone. I think it’s ok.
> > > > > > > >> > > > For standalone, multiple bundles help nothing, right?
> > > > > > > >> > > > No rebalance will happen for a standalone.
> > > > > > > >> > > >
> > > > > > > >> > > > Thanks,
> > > > > > > >> > > > Penghui
> > > > > > > >> > > >
> > > > > > > > >> > > > > On Dec 7, 2022, at 11:23, Yunze Xu 
> > > > > > > > >> > > > >  > > >
> > > > > > >> > > wrote:
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > The change of a default value is acceptable in a 
> > > > > > > > >> > > > > major release.
> > > > >> But
> > > > > > > > >> > > > > since it's changed back in the next 2.12 release, it 
> > > > > > > > >> > > > > could be a
> > > > > >> > little
> > > > > > > > >> > > > > confusing. My perspective is to include this PR in 
> > > > > > > > >> > > > > the 2.11.0
> > > > > >> > release.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Thanks,
> > > > > > > > >> > > > > Yunze
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > On Wed, Dec 7, 2022 at 11:00 AM Zixuan Liu 
> > > > > > > > >> > > > > 
> > > > > >> > wrote:
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> Pulsar 2.11 standalone breaks the bundle of 
> > > > > > > > > >> > > > >> namespace policy.
> > I'm
> > > > > > > >> > > > wondering
> > > > > > > > > >> > > > >> whether blocking the Pulsar 2.11 release.
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> See https://github.com/apache/pulsar/pull/18755
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> Thanks,
> > > > > > > > > >> > > > >> Zixuan
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> Enrico Olivelli  
> > > > > > > > > >> > > > >> 于2022年12月6日周二 21:26写道：
> > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >>> +1 (binding)
> > > > > > > > > > >> > > > >>> - verified checksums, digests
> > > > > > > > > > >> > > > >>> - built from sources
> > > > > > > > > > >> > > > >>> - tested the docker image built from sources 
> > > > > > > > > > >> > > > >>> and the docker
> > > > >> image
> > > > > > > > > > >> > > > >>> provided as convenience with the VOTE
> > > > > > > > > > >> > > > >>> - run successfully the Jakarta JMS 2.0 TCK 
> > > > > > > > > > >> > > > >>> against those two
> > > > >> docker
> > > > > > > >> > > > images
> > > > > > > > > > >> > > > >>>
> > > > > > > > > > >> > > > >>> My problem with the JMS TCK is that the 
> > > > > > > > > > >> > > > >>> behaviour of "delete
> > > > >> topic"
> > > > > > > > > > >> > > > >>> with "force=true" changed, and now if the 
> > > > > > > > > > >>

Re: [VOTE] Pulsar Release 2.11.0 Candidate-2

[PengHui Li]

Thanks, Mattison

It's better also to have https://github.com/apache/pulsar/pull/18755 for
the next RC
I have merged the PR.

Penghui

On Thu, Dec 8, 2022 at 1:53 PM  wrote:

> Hi, All
>
> I found two regressions that need to block this release.
>
> https://github.com/apache/pulsar/pull/18816
> https://github.com/apache/pulsar/pull/18812
>
>
> Best,
> Mattison
> On Dec 8, 2022, 07:15 +0800, Massimiliano Mirelli <
> massimilianomirelli...@gmail.com>, wrote:
> > Hi,
> > I am running some long-lasting tests on this rc at the moment. Would it
> be
> > OK to close the vote EOW or could you give me another 20h?
> > Thank you,
> > Max
> >
> > On Wed, 7 Dec 2022, 18:47 Nicolò Boschi,  wrote:
> >
> > > Just realized that the error doesn't block the producer but it's only
> > > related to some DNS caching optimizations.
> > > I believe we can proceed with the current rc
> > >
> > > Nicolò Boschi
> > >
> > >
> > > Il giorno mer 7 dic 2022 alle ore 17:40 Nicolò Boschi <
> > > boschi1...@gmail.com>
> > > ha scritto:
> > >
> > > > > I'm sorry but I think I've found a blocker issue.
> > > > >
> > > > > pulsar-perf doesn't support jdk17.
> > > > > I know client compatibility targets jdk8 but the image uses jdk17
> and
> > > this
> > > > > may be very annoying if pulsar-perf is not usable within the
> official
> > > > > docker image.
> > > > >
> > > > > btw I've send out the fix:
> https://github.com/apache/pulsar/pull/18806
> > > > >
> > > > >
> > > > > Nicolò Boschi
> > > > >
> > > > >
> > > > > Il giorno mer 7 dic 2022 alle ore 16:53 Zixuan Liu <
> node...@gmail.com>
> > > ha
> > > > > scritto:
> > > > >
> > > > > >> Ok, sounds good.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> Zixuan
> > > > > >>
> > > > > >> PengHui Li  于2022年12月7日周三 16:10写道：
> > > > > >>
> > > > > > > >> > > I'm wondering whether affecting the resource quota.
> Could you
> > > confirm
> > > > > > >> > that?
> > > > > > >> >
> > > > > > >> > Hmmm, I haven't heard of anyone using this feature.
> > > > > > >> > I think it should be ok for a standalone.
> > > > > > >> >
> > > > > > >> > Penghui
> > > > > > >> >
> > > > > > >> > On Wed, Dec 7, 2022 at 1:33 PM Zixuan Liu <
> node...@gmail.com> wrote:
> > > > > > >> >
> > > > > > > > >> > > > If it only affects standalone. I think it’s ok.
> > > > > > > >> > >
> > > > > > > >> > > Right.
> > > > > > > >> > >
> > > > > > > > >> > > > For standalone, multiple bundles help nothing,
> right?
> > > > > > > >> > >
> > > > > > > >> > > I'm wondering whether affecting the resource quota.
> Could you
> > > confirm
> > > > > > >> > that?
> > > > > > > >> > >
> > > > > > > >> > > Thanks,
> > > > > > > >> > > Zixuan
> > > > > > > >> > >
> > > > > > > >> > > PengHui Li  于2022年12月7日周三
> 12:53写道：
> > > > > > > >> > >
> > > > > > > > >> > > > Hi Zixuan,
> > > > > > > > >> > > >
> > > > > > > > >> > > > If it only affects standalone. I think it’s ok.
> > > > > > > > >> > > > For standalone, multiple bundles help nothing,
> right?
> > > > > > > > >> > > > No rebalance will happen for a standalone.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Thanks,
> > > > > > > > >> > > > Penghui
> > > > > > > > >> > > >
> > > > > > > > > >> > > > > On Dec 7, 2022, at 11:23, Yunze Xu
>  > > > >
> > > > > > > >> > > wrote:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > The change of a default value is acceptable in
> a major release.
> > > > > >> But
> > > > > > > > > >> > > > > since it's changed back in the next 2.12
> release, it could be a
> > > > > > >> > little
> > > > > > > > > >> > > > > confusing. My perspective is to include this PR
> in the 2.11.0
> > > > > > >> > release.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > Thanks,
> > > > > > > > > >> > > > > Yunze
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > On Wed, Dec 7, 2022 at 11:00 AM Zixuan Liu <
> node...@gmail.com>
> > > > > > >> > wrote:
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> Pulsar 2.11 standalone breaks the bundle of
> namespace policy.
> > > I'm
> > > > > > > > >> > > > wondering
> > > > > > > > > > >> > > > >> whether blocking the Pulsar 2.11 release.
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> See
> https://github.com/apache/pulsar/pull/18755
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> Thanks,
> > > > > > > > > > >> > > > >> Zixuan
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> Enrico Olivelli 
> 于2022年12月6日周二 21:26写道：
> > > > > > > > > > >> > > > >>
> > > > > > > > > > > >> > > > >>> +1 (binding)
> > > > > > > > > > > >> > > > >>> - verified checksums, digests
> > > > > > > > > > > >> > > > >>> - built from sources
> > > > > > > > > > > >> > > > >>> - tested the docker image built from
> sources and the docker
> > > > > >> image
> > > > > > > > > > > >> > > > >>> provided as convenience with the VOTE
> > > > > > > > > > > >> > > > >>> - run successfully the Jakarta JMS 2.0
> TCK against those two
> > > > > >> docker
> > > > > > > > >> > > > image

Re: [Vote] PIP-223: Add metrics for all Rest Endpoints

[Jiuming Tao]

bump, need one more binding

Jiuming Tao  于2022年11月28日周一 16:47写道：

> Dear Pulsar Community,
>
> Please review and vote on this PIP.
>
> PIP link: https://github.com/apache/pulsar/issues/18560
>
> Discuss thread:
> https://lists.apache.org/thread/z74vcn0yolzzrcc4ftonm9j3nbk4pzxm
>
> Thanks,
> Tao Jiuming
>

Re: [DISCUSS] Transactions isolation design

[丛搏]

Hi, All:
For question 1:
The transaction itself is likely to be executed across multiple
tenants. Applying for `TxnID` does not mean that it belongs to a
specific tenant (or namespace). It means that it cannot be completely
isolated. TC in the tenant will store another tenant topic register
consume or send log, it's weird. The transaction is an independent
coordinator, it does not depend on anything,
`TransactionMetadataStore` is a plug-in, which means that users can
implement TransactionMetadataStore and use user-defined Authorization
Provider. Therefore, I think the feature of tenant isolation is not
suitable for transaction coordinator, and it does not need the feature
of tenant isolation. now logic when TC unload, client will retry the
op and don't throw the exception
For question 2:
I think using the new specific endpoint (in the binary protocol) is
better, TC can be implemented by the user self,
`TransactionMetadataStoreProvider` can return the result of the new
command. And implement transaction rights management in
`TransactionMetadataStoreProvider`

Thanks,
bo

Nicolò Boschi  于2022年12月5日周一 19:41写道：
>
> Hi folks,
>
> I recently opened an issue about transactions [0]. The specific issue is
> the client requires to be able to lookup the system topic
> pulsar/system/transaction_coordinator_assign to get all the transaction
> coordinators to dial with.
>
> Since multi-tenancy is a core feature in Pulsar, this requirement may lead
> to authorization issues in multi-tenant clusters breaking the tenant
> isolation principle.
>
> In this thread I'd like to discuss, more in general, the approach that has
> been taken while designing transactions.
> The main concern I have is that TCs are global.
> A TC is backed by two system topics: transaction_coordinator_assign and
> __transaction_log_x.
> Both are used in the transaction's hot path with different workloads.
> This leads to potential critical issues:
>
> 1. *if somehow one of these topics is unloaded, ALL the tenants using
> transactions will suffer micro-outages*. (haven't looked at the error
> handling but I suppose the error would be thrown in the client's face). In
> general, availability and performance are not granted anymore
> per-tenant/namespace.
>
> I believe the TC should be per-tenant (maybe per-namespace?).
> *Is there any strong reason why this shouldn't be possible by design?* (and
> I mean, regardless of the current implementation and client-server
> compatibility, we can handle them somehow but it's a detail atm)
>
>
> One thing that I believe should be possible at the moment (but I'm not
> sure) are cross-tenant transactions. This wouldn't be possible anymore with
> per-tenant TC-
>
> 2. *the clients need lookup permission to get all the TCs*.
> (transaction_coordinator_assign partitions). This can be solved in
> different ways, even keeping using the TC as a system entity.
>
> At the moment the java client, when starting, needs to get all the
> available TCs to spread transactions over them. The call it does
> is getPartitionedTopicMetadata to the system topic.
> To fix this there are multiple ways:
> a. Suggest to users to extend their own PulsarAuthorizationProvider to
> always allow lookup to that particular topic. (quick, works with all the
> existing clients and it only requires broker/proxy restarts without token
> invalidations) However it's not builtin so this is not optimal. More
> details here: [1]
> b. Add a new auth action LOOKUP in order to allow cluster admins to give
> this permission to their clients without affecting the produce or consume
> ability. This would require only broker restarts plus operational costs for
> the admin.
> c. Creates a new specific endpoint (in the binary protocol) to give all the
> required info to the TC client to properly initialize. This would be the
> preferred solution because the permission would be granular to this
> protocol call and it wouldn't require any permission changes for the
> current applications. However, only new clients (and brokers) may use this
> solution.
>
> I believe the c. option would be great for the mid-term.
> Anyway, if the per-tenant TC is designable, then this issue would be
> resolved as well.
>
>
> [0] https://github.com/apache/pulsar/issues/18716
> [1] https://github.com/apache/pulsar/pull/18718
>
>
> BR,
> Nicolò Boschi